-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Page data HMR #3132
Page data HMR #3132
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 10 Ignored Deployments
|
*/ | ||
function subscribePageData({ assetPrefix }: { assetPrefix: string }) { | ||
const pageChunkPath = location.pathname.slice(1); | ||
const dataPath = `_next/data/development/${pageChunkPath}.json`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we also need to update this on client side navigation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. I've updated it so it unsubscribes and resubscribes when navigating to a different page.
333d500
to
b80c5c2
Compare
|
b80c5c2
to
a272d49
Compare
Benchmark for 23cd37aClick to view benchmark
|
628f0a5
to
680803d
Compare
@@ -249,8 +261,11 @@ function handleSocketMessage(msg: ServerMessage) { | |||
} | |||
} | |||
|
|||
export function onChunkUpdate(chunkPath: ChunkPath, callback: UpdateCallback) { | |||
onUpdate( | |||
export function onChunkUpdate( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should have consistent naming here, other functions above and below start with subscribeTo
, this one with on
Benchmark for e8f5344Click to view benchmark
|
Benchmark for a69f100Click to view benchmark
|
Based on vercel/turbo#2968 This builds upon vercel/turbo#2968 and @ForsakenHarmony's work on data routes to enable page data HMR. Page data HMR is a bit more clever than it is in Next.js as we won't re-render a Node.js result for each page file update. Instead, thanks to the `StripPageDefaultExport` transform, there are three versions of the page chunks: * client-side (strips page data exports); * server-side (full); * data server-side (strips page default export). Instead of subscribing to the full server-side result, on hydration, the client-side page separately subscribes to: * client-side updates (already the case); * data server-side updates (new). This means that updating something that only affects the page component will only cause a client-side update and **no Node.js re-rendering**, while updating something that only affects the data will only cause a server-side update. ~~I'm marking this as a draft for now as there are still a few areas to test/investigate:~~ - [x] When something that is used in both the default page export and data exports is changed, this will cause *two* HMR updates: one data update, and one client-side chunk update. **The same case breaks in Next.js, where we will receive a client-side update, but no server-side update, ending up with an incorrect result.** - [x] Differences between `getStaticProps/getServerSideProps`, as well as `getInitialProps` (need to talk with @timneutkens about this) (see #44523) Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Based on vercel/turbo#2968 This builds upon vercel/turbo#2968 and @ForsakenHarmony's work on data routes to enable page data HMR. Page data HMR is a bit more clever than it is in Next.js as we won't re-render a Node.js result for each page file update. Instead, thanks to the `StripPageDefaultExport` transform, there are three versions of the page chunks: * client-side (strips page data exports); * server-side (full); * data server-side (strips page default export). Instead of subscribing to the full server-side result, on hydration, the client-side page separately subscribes to: * client-side updates (already the case); * data server-side updates (new). This means that updating something that only affects the page component will only cause a client-side update and **no Node.js re-rendering**, while updating something that only affects the data will only cause a server-side update. ~~I'm marking this as a draft for now as there are still a few areas to test/investigate:~~ - [x] When something that is used in both the default page export and data exports is changed, this will cause *two* HMR updates: one data update, and one client-side chunk update. **The same case breaks in Next.js, where we will receive a client-side update, but no server-side update, ending up with an incorrect result.** - [x] Differences between `getStaticProps/getServerSideProps`, as well as `getInitialProps` (need to talk with @timneutkens about this) (see #44523) Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Based on #2968
This builds upon #2968 and @ForsakenHarmony's work on data routes to enable page data HMR.
Page data HMR is a bit more clever than it is in Next.js as we won't re-render a Node.js result for each page file update. Instead, thanks to the
StripPageDefaultExport
transform, there are three versions of the page chunks:Instead of subscribing to the full server-side result, on hydration, the client-side page separately subscribes to:
This means that updating something that only affects the page component will only cause a client-side update and no Node.js re-rendering, while updating something that only affects the data will only cause a server-side update.
I'm marking this as a draft for now as there are still a few areas to test/investigate:getStaticProps/getServerSideProps
, as well asgetInitialProps
(need to talk with @timneutkens about this) (see Exclude development from static html/json render on data request next.js#44523)