Spike: Investigate app router functionality

[timcosgrove]

Description

https://nextjs.org/docs/app

The App Router is a new paradigm for building applications using React's latest features. If you're already familiar with Next.js, you'll find that the App Router is a natural evolution of the existing file-system based router in the Pages Router.

For new applications, we recommend using the App Router. For existing applications, you can incrementally migrate to the App Router.

Acceptance criteria

• Identify pros/cons of moving to App Router (App Router vs. Pages Router)
• Determine if App Router use is compatible with next-drupal
• Document what steps are necessary to migrate next-build from Page router to App router

[ryguyk]

Overview

According to Next.js documentation, App Router is the suggested path for building new applications. The documentation also provides a guide for incremental adoption for applications that were initially built using the Pages Router.

Our application is not "new", per se, but it is relatively green and probably a really good time to consider migrating. This spike is aimed at determining the pros and cons of that move, as well as the necessary steps to perform the migration.

Pros/Cons

Pros

• It seems like App Router is the paradigm that will be supported going forward. This is not to say that Pages Router is deprecated. It is not. But it feels very noteworthy that the Next.js team suggests using the App Router.
• The real foundation of the App Router is its accommodation of React Server Components. Using React Server Components could have a significant positive impact on the javascript bundle size we send to the browser. Currently, with vets-website handling almost all of the browser javascript, it seems like this might not matter. However, components in the Pages Router are Client Components by default, and while they are initially rendered at build time, the javascript used to render them is bundled and shipped to the browser to hydrate the page. Therefore, migrating to the App Router could save a significant amount of pointless javascript from reaching the browser. A statically generated site without browser javascript is likely a perfect use case for React Server Components. We should likely not be using Client Components - the default provided by Pages Router - for our top-level pages.

Cons

• Revalidation is handled differently in App Router and it might be a regression.
  • It's very difficult to know how big an obstacle this is without having a better understanding of how we might handle revalidation/incremental builds, but this feels like an important consideration.
• Would require work to migrate. This lift does not seem heavy, but it's non-zero. See steps below.

Other considerations

We make use of next-drupal, so we need to know if that library is compatible with the App Router. As I understand things, the answer to that question is that App Router is compatible with next-drupal. There is no tight coupling between next-drupal and the mechanism that distinguishes Pages Router from App Router. next-drupal provides some utilities for fetching data, but its abstraction layer does not depend on the API provided by Pages/App Router. In Pages Router, static-page data is fetched in getStaticProps. In App Router, it's fetched within the component code itself. That difference should have no bearing on usage of the utilities provided by next-drupal. Those utilities should work in either case.
Upon deeper investigation, next-drupal seems to not support App Router.

Steps to migrate to App Router

General guide

A general guide is available in the Next.js documentation

Some specific steps for our install

• Move all pages from a file under pages to a directory under app
  • Ex:pages/[[...slug]].tsx becomes app/[[...slug]]/page.tsx
• On each of those pages, replace getStaticPaths with generateStaticParams.
• On each of those pages, remove getStaticProps. Move data fetching into component body.
• Replace pages/_document.tsx and pages/_app.tsx with a root layout.
• Move pages/api/* to app/api/* and update code to use Route Handlers.
• Fix type errors or force strictNullChecks: false
  • When running next build with App Router enabled, tsconfig.json is automatically updated to add strictNullChecks: true, which has the effect of flagging a number of type errors that previously were not flagged. The errors seem legitimate, and will take some time to resolve if we choose to do so. Otherwise, we should consider changing it to false.