Upgrading Nhost to Nextjs14

This theme comes with the @astrojs/mdx integration installed and configured in your astro.config.mjs config file. If you prefer not to use MDX, you can disable support by removing the integration from your config file.

I had avoided it for too long. Each pass at it had left me frustrated with it, so I would involve myself with other pursuits instead of getting it done. It started to become the elephant in the room for me. How can I respect myself if I can’t upgrade my Nhost/NextJS application that was working fine on NextJS 12 to NextJS 14+? Isn’t it a matter of just sprinkling some:

'use client'

everywhere? How hard could it be? Don’t I know how to render data on the server? getServerSideProps , anyone? I mean - this can’t be that hard, can it? I’m here going to share with you the process I took to update my code on AgSilo.com to the new data-fetching paradigm.

What I started with

You really have to think through every decision you’ve made and potentially restructure everything. For instance, I had a landing page that had all of the listings sorted by distance for a user which would link to detail pages which were statically generated at build time but also effectively server-side rendered by the slug variable from the path. This means I’ll have to ensure that I have a getStaticPaths method on that /equipment/[slug]/page which lets me fetch all the equipment to get rendered at build time.

To get started, I started by reading the official checklist for capturing data server side for getting my pages to render on first request, fully with their data.

Standard getServerSideProps call

export const getServerSideProps = (async () => {
  // Fetch data from external API
  const res = await fetch('https://api.github.com/repos/vercel/next.js')
  const repo: Repo = await res.json()
  // Pass data to the page via props
  return { props: { repo } }
}) satisfies GetServerSideProps<{ repo: Repo }>

The first step was to realize that having a useQuery hook from the Apollo Client in any components would mean that was a client component and would need a use client directive at the top of the file. But these were components with data that I would want to be rendered on the server because I wanted the content searchable by search engines - this site is a marketplace of used tractors so the listing pages weren’t constantly updating but we wanted them to load quickly, be indexable by the crawlers and unless there’s some way we’re going to accomplish both the server content and an updating client component in the same approach, we’ll pursue that, but first approach should be to make sure these components don’t need any client-side javascript to render.