You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For pages not returned in the list of slugs on initial call of getStaticPaths (for example, a new page added or a non existent page), no HYDRATE action is dispatched when I use incremental regeneration with getStaticPaths with fallback set to true. No HYDRATE action leads to the server side state not getting propagated to client side state for those particular pages
The following is the dependency versions I was using when seeing this issue
To reproduce use the codesandbox I created and go through the following steps: Link to codesandbox
Steps to reproduce the behavior:
Once in codesandbox click the "Open Navigator" button
2. Add `/testPage` to the URL
3. Notice how the `page` state is still `init` and not `testtest` as it should be showing as `getStaticProps` in the `slug.tsx` file dispatches an action with the payload `testtest`
Note that if you use the page link to get to the test page you do not see this issue. This is likely because when a page with fallback: true is navigated to through next/link or next/router (client-side) Next.js will not serve a fallback and instead the page will behave as fallback: 'blocking'.
The text was updated successfully, but these errors were encountered:
I have the same exact problem, using getStaticProps and fallback: true returned from getStaticPaths, the HYDRATE action is never dispatched on the client side. You find any solutions?
Describe the bug
For pages not returned in the list of slugs on initial call of
getStaticPaths
(for example, a new page added or a non existent page), no HYDRATE action is dispatched when I use incremental regeneration withgetStaticPaths
with fallback set totrue
. No HYDRATE action leads to the server side state not getting propagated to client side state for those particular pagesThe following is the dependency versions I was using when seeing this issue
To Reproduce
To reproduce use the codesandbox I created and go through the following steps:
Link to codesandbox
Steps to reproduce the behavior:
2. Add `/testPage` to the URL
3. Notice how the `page` state is still `init` and not `testtest` as it should be showing as `getStaticProps` in the `slug.tsx` file dispatches an action with the payload `testtest`
Note that if you use the page link to get to the test page you do not see this issue. This is likely because when a page with
fallback: true
is navigated to through next/link or next/router (client-side) Next.js will not serve a fallback and instead the page will behave as fallback: 'blocking'.The text was updated successfully, but these errors were encountered: