Conversation
Stats from current PRClick to expand stats
Click to expand serverless stats
|
|
Apologies for the first commit, I hadn't installed git hooks, and it let me commit all of my files without running prettier and standard. It was just linty stuff :) |
Stats from current PRClick to expand stats
Click to expand serverless stats
|
|
This is amazing! Is it assuming that the app is dynamic(fetches data from backend) but the data itself is static? Not sure if I understand how this will work when data changes |
|
@chirag04 - thanks for your comment. No, there is no assumption that the data is static. The dynamic routes are generated from the Express.js-style routes in the |
Stats from current PRClick to expand stats
Click to expand serverless stats
|
Stats from current PRClick to expand stats
Click to expand serverless stats
|
|
Hey @baer, I ended up writing #7355 based on this feedback and a bunch of other feedback 👍 Let's discuss more there if needed 👌
Thank you 😌🙏 |
Over the last year, I have used (and loved) Next.js to build several large React applications. I'm somewhat of an evangelist - it's an outstanding platform and an incredibly well-run project.
There is a body of uses cases, however, that are not well covered by the current examples or documentation: statically deployed applications where the data can't be determined at build time. Applications like these are common when page data is time-sensitive, too-large, user-specific, or can't reliably be fetched from a build server. Even when data is readily available, some developers prefer to use the App Shell Model, where an application bundle contains fully compiled, but empty, pages.
Despite my best efforts, Using Next.js for applications like this requires a fair amount of complexity. I'd like to use this PR as a place to discuss:
If the Zeit/Next.js team decides that additional work to make this easier is not a priority, this example at least gives some guidance to other developers who would like to try similar things.
Areas for discussion:
Note: I've already included most of these discussion points as comments in the code. I figured that, if the PR is merged ahead of or without changes to Next.js, these would be good guideposts for other developers.
Configuration for route translation
Applications with dynamically defined routes need configuration in three places:
next.config.js- TheexportPathMapdefines the set of routes to exportserver.js- The development server needs the set of routes, and their translation into Next.js pages, in the Express path formatserve.json(or other CDN configuration) - The CDN needs the set of routes, and their translation into static paths, in the format required by that CDNIn my application, I've defined redirects in a file called
redirects.jswhich I then read from Express and thenext.config.js. I also use that file to generate the configuration for Serve.Handling of URI parameters for static pages
When re-hydrating a statically compiled Next.js page, Next.js will ignore query parameters. For example, for the URL http://myapp.com?page=1,
this.props.router.queryis{}. The reason for this is that if Next.js were to process the parameters, React's virtual DOM might not match the statically rendered one which can cause React to fail in weird ways. One solution (proposed in #4341) is to trigger a second render if there are query parameters.The Link tag
For dynamic pages (in a static application), using the Link component without an
asproperty causes a full-page refresh. Since the symptom is, just a slightly slower page transition, this is an easy bug to introduce - especially now that the Next.js dev server compiles pages in real-time. Depending on whether your state (Redux, MobX, etc.) is stored in memory, and if performance is critical to your app, this could be anything from a non-issue to a show-stopper.Again, thank you for your hard work and for your contributions the the ecosystem!