-
-
Notifications
You must be signed in to change notification settings - Fork 115
RFC: useMatches hook + layout loaders #656
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
Merged
Merged
Conversation
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
Deep research and implementation plan for: 1. Layout loaders - allow _layout.tsx to export loader() 2. useMatches() hook - access all matched routes' loader data Key findings: - route.layouts already tracked in getServerManifest.ts - cli/build.ts:273 skips _layout files (need to fix) - fileSystemRouterPlugin.tsx only runs page loader (need to fix)
|
🚅 Deployed to the one-pr-656 environment in onestack.dev
|
- Add useMatches() hook to access all matched routes' loader data - Add useMatch(routeId) to find a specific match by route ID - Add usePageMatch() to get the current page's match - Support layout loaders - _layout.tsx can export loader() functions - Run layout loaders in parallel on both dev and production servers - Add build system support for layout server paths - Add One.RouteMatch type for type safety - Add tests for useMatches functionality
- Pass matches array to render function in dev server - Add tests for dynamic params, catch-all params - Add tests for complex loaderData scenarios - Add tests for finding matches by routeId
Document that layout loader data is cached from SSR on client-side navigation since One intentionally doesn't re-run loaders on client.
- Add buildClientMatches() to construct matches array after navigation - Add initClientMatches() to initialize from server context on hydration - Call setClientMatches() in linkTo after preload completes - Add e2e tests for useMatches with client navigation
- Fix layout loaders not running for SSG routes in production - Add layout server path tracking during build for SSG routes - Preserve minimal layout info in buildInfo.json for loader execution - Simplify buildClientMatches to preserve layout matches on navigation - Fix useMatches always returning client store on client (not hydrated data) - Fix contextKey format mismatch in layout server paths (./path vs /path)
When route.file or serverPath already contains dist/server (from loaderServerPath), don't prepend it again. This fixes SSR loader redirects in production builds.
Tests 3+ levels of nested layouts with loaders to verify: - 4 matches total (root layout, level1 layout, level2 layout, page) - Each layout can access its own loader data via useMatch - Page can access all layout loader data via useMatches
- Add test for useMatches with dynamic routes (params in matches) - Add error handling test setup (currently skipped) - Add error handling for loader failures in dev server - Update plan document with completed items
Avoids conflicts with common dev servers like 8081
- Add hooks-test page to test useMatch and usePageMatch hooks - Test useMatch with valid routeId finds the match - Test useMatch with invalid routeId returns undefined - Test usePageMatch returns current page match - Test matches are consistent after hydration
9ae645b to
7b7076f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
Research and implementation plan for allowing layouts to access loader data on SSR.
Proposed Features
_layout.tsxfiles to export aloader()functionUse Case
DocsQuickNav in tamagui.dev layout needs
frontmatter.headingsfrom the page's loader to render statically (avoid hydration flash).Key Findings from Research
route.layoutsis already tracked ingetServerManifest.ts:49,73cli/build.ts:273skips_layoutfiles - needs to include them for server buildsfileSystemRouterPlugin.tsx:84-88only runs page loader - needs parallel layout executionImplementation Phases
Client-Side Note
One intentionally doesn't run loaders on client-side navigation. This is preferred and will remain unchanged.
useMatches()on client will return cached/hydrated data from SSR.See
plans/loader-overhaul.mdfor full technical details.Test Plan