84aeded02f
The original motivation of this PR is to get `unstable_cache` into a state where I can more easily change the implementation of postpone to be more akin to "dynamic rendering APIs". the existing approach made typing the staticGenerationStore in a way I wanted to for the planned changes would have been hard to implement with the current approach. At the same time this was an opportunity to make the implementation more efficient and easier to reason about. reorganizes unstable_cache to improve performance and potentially fix latent bugs related to nest cache calls In the original implementation there are repeated defined checks for the store and relatively complex logic around gathering the cache entry. In my refactor I fork the implementation based on whether we have a store or not. Loosely this translates to whether the cache call is for App Router vs Pages Router however due to a quirk in how we scope inner cache calls there is an existing and unchanged case where a Pages Router cached callback runs with a "fake" store that is used to scope some cache values to prevent inner caching when one cached function calls another. It should be noted that this fake store technique means that inner cache calls inside Pages Router will hit the App Router pathway in unstable cache. This is not great but it is the current behavior and while I have made some changes that might fix some bugs changing this felt like a much bigger lift to do in a primarily refactor PR. This "fake" store can be replaced by a different async store for Pages Router which we can use to scope the inner environment to not be cached eventually though it may make more sense to just generalize the staticGenerationStore into a kind of RenderStore and have it run for Pages Router too. I moved as much computation that can be done in the closure around the cached function out of the cached function and I narrowed the scope of the run call to make it clear that we really only need to scope the callback. I removed function allocations per invocation I probably fixed a bug in how the revalidate property was refined on the static generation store. Previously it would be possible to go from number to false and back again but this doesn't make sense as false is more like INFINITY in terms of refining to shorter values. This PR updates this logic to be apparently Closes NEXT-2028 |
||
|---|---|---|
| .. | ||
| create-next-app | ||
| eslint-config-next | ||
| eslint-plugin-next | ||
| font | ||
| next | ||
| next-bundle-analyzer | ||
| next-codemod | ||
| next-env | ||
| next-mdx | ||
| next-plugin-storybook | ||
| next-polyfill-module | ||
| next-polyfill-nomodule | ||
| next-swc | ||
| react-dev-overlay | ||
| react-refresh-utils | ||
| third-parties | ||