You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use nested routes throughout to better handle things with found-relay and just general organization improvements. A sample URL is /organizations/:organizationId/parameters. I tried to redirect from /organizations/:organizationId/dataStore to /organizations/:organizationId/parameters with:
I can show the full hierarchy if needed, but hopefully you can see that the path field here corresponds to the last part of the URL. The issue is, this semi-redirects. The URL will be replaced with the correct one, but a 404 HttpError will also be thrown. It's a bit tricky to trace through, but I can see the initial RedirectException is thrown, but is subsequently rewritten to a 404 HttpError because resolveRenderArgs is unable to find a match for the rewritten match:
As far as I can tell, the problem here is because the original match object doesn't contain the full path of the match, only the local path from the nested route. This causes routes to be null and consequently, the 404 HttpError is thrown. Elsewhere, the redirect seems to go through and rewrite the URL, leading to an overall confusing situation.
I found that if I treated the redirect as a flat route, that things worked:
I'm happy to have a solution, but it'd be nice if we could make use of our existing nesting structure. Alternatively, if nested redirects are not supported, it'd be helpful to have a runtime error that fails entirely. The current half-working, half-failing case makes it unclear what the problem is.
The text was updated successfully, but these errors were encountered:
Yeah, there isn't really any support for relative routes right now. Essentially the issue is that it's not totally clear what things should be relative to. I'm not sure why we don't just throw an exception in these cases TBH.
We use nested routes throughout to better handle things with found-relay and just general organization improvements. A sample URL is /organizations/:organizationId/parameters. I tried to redirect from /organizations/:organizationId/dataStore to /organizations/:organizationId/parameters with:
I can show the full hierarchy if needed, but hopefully you can see that the path field here corresponds to the last part of the URL. The issue is, this semi-redirects. The URL will be replaced with the correct one, but a 404
HttpError
will also be thrown. It's a bit tricky to trace through, but I can see the initialRedirectException
is thrown, but is subsequently rewritten to a 404HttpError
becauseresolveRenderArgs
is unable to find a match for the rewritten match:found/src/resolveRenderArgs.js
Lines 33 to 46 in 5d790f4
As far as I can tell, the problem here is because the original
match
object doesn't contain the full path of the match, only the local path from the nested route. This causesroutes
to benull
and consequently, the 404HttpError
is thrown. Elsewhere, the redirect seems to go through and rewrite the URL, leading to an overall confusing situation.I found that if I treated the redirect as a flat route, that things worked:
I'm happy to have a solution, but it'd be nice if we could make use of our existing nesting structure. Alternatively, if nested redirects are not supported, it'd be helpful to have a runtime error that fails entirely. The current half-working, half-failing case makes it unclear what the problem is.
The text was updated successfully, but these errors were encountered: