fix: explode optional segments for relative paths in nested routes #9684
Conversation
|
pcattori
changed the title
pcattori
force-pushed
the
pedro/explode-optional-segments
branch
from
9d5a7d9
to
ae6a2db
Compare
explicitly 'explode' path with optional path segments.
pcattori
force-pushed
the
pedro/explode-optional-segments
branch
from
ae6a2db
to
8688e60
Compare
pcattori
changed the title
| }); | ||
| for (let exploded of explodeOptionalSegments(route.path)) { | ||
| flattenRoute(route, index, exploded); | ||
| } |
There was a problem hiding this comment.
I think this is close - but I'm still seeing some ?'s in flattened paths (and also in the then-generated routesMeta.relativePath. I think always as part of the last optional segment? Here's the flattened/ranked paths for the unit test above:
Otherwise the routesMeta relative paths are looking right to me though!
There was a problem hiding this comment.
I'll try to hit this with a few more complex unit tests scenarios tomorrow as well 👍
There was a problem hiding this comment.
Yes, forgot to update code to handle empty segments for nested routes. Should work now!
pcattori
force-pushed
the
pedro/explode-optional-segments
branch
from
88b04a3
to
28836f2
Compare
pcattori
force-pushed
the
pedro/explode-optional-segments
branch
from
d76bc59
to
e4cc374
Compare
#9650 added support for matching routes with optional path segments, but did not work for nested routes.
This PR fixes that.
It also refactors the approach to explicitly "explode" a path with optional path segments into the equivalent set of valid combinations of paths without optional segments (see
explodeOptionalSegmentsjsdoc for an example). The paths are "exploded" prior to creating the route metadata, which means that when the route metadata gets initialized its already correct. Previously, we needed to surgically modify route metadata for a branch (which we were only handling correctly for unnested routes).