Are parent loaders always meant to overrule child loaders?

[stuartkeith]

Say I have the following routing setup:

• /<id> - will throw a 404 if id is not a number
• /<id>/redirect - will throw a redirect to /<id>/example
• /<id>/example - a normal page

If I go to /123/redirect, I am redirected to /123/example as expected.

But if I go to /foo/redirect, I am redirected to /foo/example. I would expect a 404 instead - the parent loader will throw a 404 as foo is not a number. I can see the parent loader does throw the 404 as expected, but the child loader's redirect takes priority.

This seems to be related to redirects specifically - if I had the child loader throw a 500 instead, the user gets the 404, the 500 is ignored.

I'm not sure if this is a bug or I'm misunderstanding how the parent/child loaders work together. Does anybody know what is going on here? Thanks.

[kiliman]

Is the /id route a parent of the other routes? Parent loaders only apply to nested routes. You won't see the desired behavior if /id is a sibling route to the others.

<Route path="/id" loader={() => throw notfound()}>
  <Route path="redirect" loader={() => throw redirect('example')}/>
  <Route path="example" />
</Route>

[stuartkeith]

Thanks for getting back to me. What I have looks similar to your example, except I'm using a data router.

Here is a repro. https://stackblitz.com/edit/github-ypg2nu-lgqn1u

It's not as easy to use as it could be - for some reason the Link components weren't working in stackblitz, so it's necessary to change the URL above the demo. It also doesn't seem to update that URL, so I am logging the current location in the error boundary.

If I change the URL to /123, then I am redirected to /123/hello as expected and everything is fine.

If I change the URL to /foo (invalid ID), then the parent loader throws a 400 because "foo" is not a number, and the child loader throws a redirect to /foo/hello.

It's a bit more subtle than I initially realised - I seem to get a mix of results. I get the 400 response from the parent loader, but the URL has been updated to /foo/hello, which the child redirect is responsible for. I would have assumed the child's redirect would be ignored as the parent threw an exception too.

[stuartkeith]

I had a look at the source - this behaviour is deliberate in that the code goes from the inner request outwards and stops at the first redirect: https://github.com/remix-run/react-router/blob/main/packages/router/router.ts#L4524-L4534.

I might open an issue for this.

[se7entyse7en]

Hi @stuartkeith I faced exactly this issue and I was puzzled. Do you have any updates? My situation is very similar:

1. a parent loader throwing 500,
2. a nested route child loader returning a redirect.

The outcome is that the redirect is performed, which is not what I was expecting. If just for testing I replace the line in the parent loader that throws a 500 with a random redirect, the random redirect is performed.

[stuartkeith]

Hi @se7entyse7en, I didn't figure this out and ended up working around it. I've just opened #11805.

[brophdawg11]

There's a discussion in #11805 but I wanted to cross-post here that I believe what you all really want for these use cases is middleware which will let you do this type of top-down control flow. Please keep an eye on that proposal for updates.