[pull] canary from vercel:canary - #1309
Merged
Merged
Conversation
Pure structural refactor, no behavior changes. This continues some of the clean-up work I've been doing in the client router now that more of the implementation has settled, post-Segment Cache and Instant Navigations. I have two primary motivations here. The first is purely maintainability. The current module structure is a mess, and the naming is misleading when browsing the codebase for the first time. The second motivation is to prepare for an upcoming rewrite of the router queue. There will likely be two simultaneous implementations for a while as the new one settles, so it's extra important the interface into the router queue is well-defined. I want the fork between the two worlds to be as clean as possible. This is a similar approach to the one I took when rewriting the prefetching implementation. Some of the key name changes: - ppr-navigations.ts → render-tree.ts. This module's responsibility is to create the tree that gets passed into React for rendering, currently called the CacheNode tree. I considered renaming it to cache-node.ts, but I kept it more generic because I have plans to refactor that type soon. - segment-cache/navigation.ts → app-router-state.ts. This module's responsibility is to compute the next AppRouterState given inputs. It does perform network requests, but it's conceptually a "pure" operation. It doesn't deal with any of the router queueing logic. This is the most reducer-y of the code that still exists, and along with render-tree.ts, it will remain mostly shared between the old and new state machine implementations. - navigator.ts. This is a new module I created to act as the single entry point for router-level operations: push, replace, navigate, traverse, restore, refresh, hmrRefresh. This is the primary place where we'll fork the old and new queue implementations. It's also how we'll ensure the inactive implementation gets dead-code-eliminated properly while the two implementations live side-by-side.
Sets up the scaffolding for a rewrite of the client router's queue. I've named the new module concurrent-router-queue.ts and the existing module sequential-router-queue.ts, since the main goal of the new one is to improve the router's integration with React's concurrent rendering model. The experimental flag is likewise named `concurrentRouterQueue`. There's no implementation yet; all router operations throw an error when the flag is enabled. The main entry point into the router is navigator.ts. The flag swaps between implementations at the module level to ensure the inactive code is eliminated from the final bundle.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )