Skip to content
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.

Sign up for GitHub

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

Jump to bottom

fix: empty generateStaticParams should still create an ISR route #73358

Merged
merged 3 commits into from
Dec 10, 2024
Merged

fix: empty generateStaticParams should still create an ISR route #73358

merged 3 commits into from
Dec 10, 2024
+113 −13

Conversation

ztanner
Copy link
Member

@ztanner ztanner commented Nov 29, 2024 •
edited
Loading

Returning an empty array from generateStaticParams should still be deployed as an ISR route to support the dynamicParams = true case, where a route can be generated & cached on demand. At the moment the only way to achieve this behavior is with export const dynamic = 'force-static'. As a result, these routes are being treated as dynamic and never return a cached response.

This PR resolves the bug by fixing several distinct things:

  • prerenderedRoutes does not need to be an array > 0 to mark a route as being a static path. This will ensure the build output shows the correct symbol and adds the path to the list of prerenders.
  • we initialize prerenderedRoutes to an empty array if we determine that the leaf-most segment (the thing rendering the current page) has a generateStaticParams function
  • the function responsible for collecting segments associated with a page only considered the children branch, but for something like a parallel/interception route, those segments would be inside of a different parallel route key
  • the regex for determining if a function was dynamic didn't consider that the dynamic route might also contain an interception marker (eg (.))

This appears to have regressed in #68125

Closes NEXT-3905

@ztanner Graphite App
Copy link
Member Author

ztanner commented Nov 29, 2024

This stack of pull requests is managed by Graphite. Learn more about stacking.

@ijjk
Copy link
Member

ijjk commented Nov 29, 2024 •
edited
Loading

Tests Passed

@ijjk
Copy link
Member

ijjk commented Nov 29, 2024 •
edited
Loading

Stats from current PR

Default Build (Increase detected ⚠️)
General Overall increase ⚠️
vercel/next.js canary vercel/next.js 11-29-fix_empty_generatestaticparams_should_still_create_an_isr_route Change
buildDuration 27.9s 18.5s N/A
buildDurationCached 17.6s 15.5s N/A
nodeModulesSize 409 MB 409 MB ⚠️ +9.78 kB
nextStartRea..uration (ms) 466ms 487ms N/A
Client Bundles (main, webpack)
vercel/next.js canary vercel/next.js 11-29-fix_empty_generatestaticparams_should_still_create_an_isr_route Change
1187-HASH.js gzip 50.2 kB 50.2 kB N/A
8276.HASH.js gzip 169 B 168 B N/A
8377-HASH.js gzip 5.3 kB 5.3 kB N/A
bccd1874-HASH.js gzip 53 kB 53 kB N/A
framework-HASH.js gzip 57.5 kB 57.5 kB N/A
main-app-HASH.js gzip 232 B 235 B N/A
main-HASH.js gzip 33.8 kB 33.7 kB N/A
webpack-HASH.js gzip 1.71 kB 1.71 kB N/A
Overall change 0 B 0 B ✓
Legacy Client Bundles (polyfills)
vercel/next.js canary vercel/next.js 11-29-fix_empty_generatestaticparams_should_still_create_an_isr_route Change
polyfills-HASH.js gzip 39.4 kB 39.4 kB ✓
Overall change 39.4 kB 39.4 kB ✓
Client Pages
vercel/next.js canary vercel/next.js 11-29-fix_empty_generatestaticparams_should_still_create_an_isr_route Change
_app-HASH.js gzip 193 B 193 B ✓
_error-HASH.js gzip 193 B 193 B ✓
amp-HASH.js gzip 512 B 510 B N/A
css-HASH.js gzip 343 B 342 B N/A
dynamic-HASH.js gzip 1.84 kB 1.84 kB ✓
edge-ssr-HASH.js gzip 265 B 265 B ✓
head-HASH.js gzip 363 B 362 B N/A
hooks-HASH.js gzip 393 B 392 B N/A
image-HASH.js gzip 4.44 kB 4.43 kB N/A
index-HASH.js gzip 268 B 268 B ✓
link-HASH.js gzip 2.35 kB 2.34 kB N/A
routerDirect..HASH.js gzip 328 B 328 B ✓
script-HASH.js gzip 397 B 397 B ✓
withRouter-HASH.js gzip 323 B 326 B N/A
1afbb74e6ecf..834.css gzip 106 B 106 B ✓
Overall change 3.59 kB 3.59 kB ✓
Client Build Manifests
vercel/next.js canary vercel/next.js 11-29-fix_empty_generatestaticparams_should_still_create_an_isr_route Change
_buildManifest.js gzip 747 B 745 B N/A
Overall change 0 B 0 B ✓
Rendered Page Sizes
vercel/next.js canary vercel/next.js 11-29-fix_empty_generatestaticparams_should_still_create_an_isr_route Change
index.html gzip 524 B 523 B N/A
link.html gzip 538 B 538 B ✓
withRouter.html gzip 520 B 520 B ✓
Overall change 1.06 kB 1.06 kB ✓
Edge SSR bundle Size
vercel/next.js canary vercel/next.js 11-29-fix_empty_generatestaticparams_should_still_create_an_isr_route Change
edge-ssr.js gzip 128 kB 128 kB N/A
page.js gzip 203 kB 203 kB N/A
Overall change 0 B 0 B ✓
Middleware size
vercel/next.js canary vercel/next.js 11-29-fix_empty_generatestaticparams_should_still_create_an_isr_route Change
middleware-b..fest.js gzip 671 B 668 B N/A
middleware-r..fest.js gzip 155 B 156 B N/A
middleware.js gzip 31 kB 31 kB N/A
edge-runtime..pack.js gzip 844 B 844 B ✓
Overall change 844 B 844 B ✓
Next Runtimes
vercel/next.js canary vercel/next.js 11-29-fix_empty_generatestaticparams_should_still_create_an_isr_route Change
523-experime...dev.js gzip 322 B 322 B ✓
523.runtime.dev.js gzip 314 B 314 B ✓
app-page-exp...dev.js gzip 322 kB 322 kB ✓
app-page-exp..prod.js gzip 127 kB 127 kB ✓
app-page-tur..prod.js gzip 140 kB 140 kB ✓
app-page-tur..prod.js gzip 135 kB 135 kB ✓
app-page.run...dev.js gzip 312 kB 312 kB ✓
app-page.run..prod.js gzip 122 kB 122 kB ✓
app-route-ex...dev.js gzip 37.1 kB 37.1 kB ✓
app-route-ex..prod.js gzip 25.1 kB 25.1 kB ✓
app-route-tu..prod.js gzip 25.1 kB 25.1 kB ✓
app-route-tu..prod.js gzip 24.9 kB 24.9 kB ✓
app-route.ru...dev.js gzip 38.7 kB 38.7 kB ✓
app-route.ru..prod.js gzip 24.9 kB 24.9 kB ✓
pages-api-tu..prod.js gzip 9.56 kB 9.56 kB ✓
pages-api.ru...dev.js gzip 11.4 kB 11.4 kB ✓
pages-api.ru..prod.js gzip 9.56 kB 9.56 kB ✓
pages-turbo...prod.js gzip 21.3 kB 21.3 kB ✓
pages.runtim...dev.js gzip 27 kB 27 kB ✓
pages.runtim..prod.js gzip 21.3 kB 21.3 kB ✓
server.runti..prod.js gzip 916 kB 916 kB ✓
Overall change 2.35 MB 2.35 MB ✓
build cache Overall increase ⚠️
vercel/next.js canary vercel/next.js 11-29-fix_empty_generatestaticparams_should_still_create_an_isr_route Change
0.pack gzip 2.04 MB 2.04 MB ⚠️ +1.36 kB
index.pack gzip 146 kB 146 kB N/A
Overall change 2.04 MB 2.04 MB ⚠️ +1.36 kB
Diff details
Diff for main-HASH.js

Diff too large to display

Commit: 25aca48

@ztanner ztanner force-pushed the 11-29-fix_empty_generatestaticparams_should_still_create_an_isr_route branch from 2de717a to 3bc84e2 Compare November 29, 2024 16:53
@ztanner ztanner force-pushed the 11-29-fix_empty_generatestaticparams_should_still_create_an_isr_route branch 2 times, most recently from cdae93f to 8dbe5c7 Compare December 9, 2024 22:02
@ztanner ztanner force-pushed the 11-29-fix_empty_generatestaticparams_should_still_create_an_isr_route branch from 8b3e14d to 024b520 Compare December 10, 2024 00:37
@ztanner ztanner force-pushed the 11-29-fix_empty_generatestaticparams_should_still_create_an_isr_route branch from 024b520 to 25aca48 Compare December 10, 2024 01:06
@ztanner ztanner marked this pull request as ready for review December 10, 2024 01:55
@ztanner ztanner requested review from wyattjoh and ijjk December 10, 2024 02:13
@ztanner ztanner merged commit 92b3dd2 into canary Dec 10, 2024
112 checks passed
@ztanner ztanner deleted the 11-29-fix_empty_generatestaticparams_should_still_create_an_isr_route branch December 10, 2024 15:05
@icyJoseph icyJoseph mentioned this pull request Dec 12, 2024
Closed
@ztanner ztanner mentioned this pull request Dec 13, 2024
Merged
ztanner added a commit that referenced this pull request Dec 13, 2024
@ztanner
refactor: collectAppPageSegments (#73908)
2889713 
This refactors `collectAppPageSegments` to be more efficient especially
when dealing with multiple parallel routes, where the number of
combinations of segments can drastically increase how many segments are
returned per route. Previously this function only considered the
`children` parallel route. When it was updated to consider all possible
parallel routes in #73358, this had the unintended side effect of
increasing the amount of duplicate segments this function would have to
process.

We only need to return unique segments discovered from a particular
loader tree (representing a page), as opposed to the same segment as
many times as it might appear across all parallel routes. This PR uses a
map to track unique segments with a composite key used to identify the
discovered segments.

Additionally, this refactors the function to be iterative rather than
recursive. We keep track of a queue of segments to be processed (a tuple
of `[loaderTree, segments]`), and as we discover new parallel route
paths, we process the queue further.

Fixes #73793
Closes #73871 (h/t to @icyJoseph for identifying the cause of the memory
consumption)
ztanner added a commit that referenced this pull request Dec 16, 2024
@ztanner
refactor: collectAppPageSegments (#73908)
8b78ca2 
This refactors `collectAppPageSegments` to be more efficient especially
when dealing with multiple parallel routes, where the number of
combinations of segments can drastically increase how many segments are
returned per route. Previously this function only considered the
`children` parallel route. When it was updated to consider all possible
parallel routes in #73358, this had the unintended side effect of
increasing the amount of duplicate segments this function would have to
process.

We only need to return unique segments discovered from a particular
loader tree (representing a page), as opposed to the same segment as
many times as it might appear across all parallel routes. This PR uses a
map to track unique segments with a composite key used to identify the
discovered segments.

Additionally, this refactors the function to be iterative rather than
recursive. We keep track of a queue of segments to be processed (a tuple
of `[loaderTree, segments]`), and as we discover new parallel route
paths, we process the queue further.

Fixes #73793
Closes #73871 (h/t to @icyJoseph for identifying the cause of the memory
consumption)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ijjk ijjk ijjk approved these changes

@wyattjoh wyattjoh Awaiting requested review from wyattjoh

Assignees
No one assigned
Labels
created-by: Next.js team PRs by the Next.js team. tests type: next
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@ztanner @ijjk @wyattjoh