Why use Next.js at all?īecause it's awesome! You can split your bundle with dynamic imports, which solves one of the biggest performance issues associated with large SPAs. If you are dead-set on using Next's routing system, you should look at those approaches. There are complex, hacky ways of achieving this in Next, including several described here by Adam Wathan. In practice it "flattens" all those routes. This is true despite the fact that Next.js nominally lets you define "nested routes" (e.g. It's equivalent to building an app with a single, top-level React Router. This isn't possible with Next's built-in router! Instead, all shared state and layout must be initialized in your custom _app.tsx component. about and /team) and nested routes (e.g. This is true for both top-level routes (e.g. It's easy for any "parent" router to share data with all of its "child" routes. Next.js is not as flexible as React Router! React Router lets you nest routers hierarchically in a flexible way. Turns out, Next.js does not make this easy. I'm referring to the "old school" SPA model: an application that handles all data fetching, rendering, and routing entirely client-side. To clarify, I'm using the term "SPA" in a very specific way. I recently set out to implement a single-page application (SPA) on top of Next.js. Those thoughts have been moved to a separate post here! Vercel, Next.js, and the war on SPAs. A previous version of this post contained a discussion regarding Vercel (the company that maintains Next.js), perverse incentives, the blurring of the static-dynamic dichotomy, and the future of the SPA paradigm.
0 kommentar(er)
