Next.js

Framework built on top of React.

Officially recommended by React^[ref]:

gothinkster/realworld blog example by Ciro Santilli: node Express Sequelize Next.js realworld example app.

Basically what this does is to get server-side rendering just working by React, including hydration, which is a good thing.

Next.js sends the first pre-rendered HTML page along with the JavaScript code. Then, JavaScript page switches just load the API data.

Next.js does this nicely by forcing you to provide page data in a serialized JSON format, even when rendering server-side (e.g. the return value of getServerSideProps). This way, it is also able to provide either the full HTML, or just the JSON.

Some general downsides:

In theory, Next.js could be the "ultimate frontend framework". It does have a lot of development difficulties that need to be ironed out, but the general concepts, and things it tries to integrate, including e.g. webpack, TypeScript, etc. are good. Maybe the question is when will someone put it together with an amazing backend library and dominate and finally put an end to the infinite number of Js Frameworks!

In-tree examples at: github.com/vercel/next.js/tree/canary/examples

canary is their master: github.com/vercel/next.js/issues/3211

In order to offer its amazing features, Next.js is also extremely opinionated, which means that if something wasn't designed to be possible, it basically isn't.

No prerender with custom server? It forces you to write your API with next as well? Or does it mean something else?

TODO can it statically generate pages that are created at runtime? E.g. if I create a new blog post, will it automatically upload a static page? It seems that yes, and that this is exactly what Incremental Static Regeneration means:However, Ciro can't find any mention of how to specify where the pages are uploaded to... this is pat of the non-Vercel deployment problem.

Can't ISR prerenter by URL query parameters:That plus the requirement to have one page per file under pages/ leads to a lot of useless duplication, because then you are forced to place the URL parameters on the pathnames.

"Module not found: Can't resolve 'fs'" Hell. The main reason this happens seems to be the that in a higher order component, webpack can't determine if callbacks use the require or not to remove it from frontend code. Fully investigated and solved at:

Overviews:

TODO answer:

Our examples are located under nodejs/next:

Solved ones:

The goal of this example is to understand when states and effects happen when changing between different routes that use the same component.

Behavior is follows:

This is likely because in React the state kept in the virtual DOM structure, and identical structure implies identical state. So when we change from post 1 to 2, we still have a Post object, and state is unchanged.

Next if we click:then the count is back to 0. This is because we changed the Post object in the DOM to Index and back, which resets everything.

This example also illustrates how to prevent this from happening with useEffect.

Bibliography:

This is a minimal reproducible example for the terrible problem of external effects applying twice to refs for effects that are not idempotent and thus blowup if applied twice.

The issue is currently discussed at: react.dev/learn/synchronizing-with-effects#step-3-add-cleanup-if-needed (archive) which says "you need to cleanup the thing yourself". web.archive.org/web/20240720100401/https://react.dev/learn/synchronizing-with-effects#subscribing-to-events is also says that for the specific case of addEventListener.

But that's annoying! Can't we just somehow tell if we applied twice or not to avoid having to implement a cleanup? What if a third party system does not provide a cleanup at all?

Is the correct solution to just just have a useEffect with empty dependency list? Seems to be good according to posts and to ESLint!

Tried to do a React only reproduction at: react/ref-twice.html.

Bibliography:

Ciro Santilli's questions:

In this example we attempt to inject React elements into statically rendered HTML coming from the server, and properly hydrate them.

Questions by Ciro Santilli:

Bibliography: