Properly handle lazy errors during router initialization #10201
Conversation
🦋 Changeset detectedLatest commit: 647dd85 The changes in this PR will be included in the next version bump. This PR includes changesets to release 5 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| element: <h1>Action</h1>, | ||
| })} | ||
| /> | ||
| </Route> |
There was a problem hiding this comment.
Altered this test so it's not loading into a lazy route, and instead is submitting to one (which is what the test is for)
| element: <h1>Path</h1>, | ||
| })} | ||
| /> | ||
| </Route> |
There was a problem hiding this comment.
Same here - load into a non-lazy route, submit form to a lazy route
| @@ -4434,72 +4475,6 @@ function testDomRouter( | |||
| `); | |||
| }); | |||
|
|
|||
| it("renders hydration errors on lazy leaf elements", async () => { | |||
There was a problem hiding this comment.
This is not a use-case we need to support (for now) since we landed on SSR needing to pre-resolve lazy for initial matches
| // in the normal navigation flow. For SSR it's expected that lazy modules are | ||
| // resolved prior to router creation since we can't go into a fallbackElement | ||
| // UI for SSR'd apps | ||
| if (!state.initialized) { |
There was a problem hiding this comment.
This goes back to exactly what we did prior to lazy. There's no "I'm half iniitalized" concept. Either both lazy and data is resolved for initial matches (SSR), or neither is (SPA).
Run
lazy()viastartNavigationinrouter.inititialize()so we can properly bubblelazy()errors to boundaries.Closes #10194