Relative path does not resolve correctly with flat file routes with redirect about remix HOT 5 CLOSED

Redirects in Remix and React Router are relative to the Route Hierarchy by default: https://reactrouter.com/en/main/start/overview#relative-links

Your route files create a route tree of:

> npx remix routes
<Routes>
  <Route file="root.tsx">
    <Route index file="routes/_index.tsx" />
    <Route path="a/b/c" file="routes/a.b.c.tsx" />
    <Route path="a/b/e" file="routes/a.b.e.tsx" />
  </Route>
</Routes>

So when you redirect('../e') from the action in the route for /a/b/c you are going "up one route" to the root, then going to e which lands you at /e. If you added a parent route file routes/a.b.tsx then you'd have the proper Route hierarchy for this approach.

Or, if you want URL-segment relative links, in the React component/shooks there's a relative="path" option for this (https://reactrouter.com/en/main/components/link#relative) but that doesn't exit for redirect which is just a wrapper around new Response(null, { status: 3xx, ... }).

For redirects, you can do it with the URL constructor:

export function loader({ request }: LoaderFunctionArgs) {
  let currentUrl = request.url.endsWith("/") ? request.url : `${request.url}/`;
  let redirectUrl = new URL("../e", currentUrl).pathname;
  return redirect(redirectUrl);
}

from remix.

Is there any use case where redirect('../e') pointing to a path depending on internals is useful? Now I understand the historical reason, but I'm curious if it could be a feature request, trading off how many people are happy as it is vs changing to relative path works out of the box.

from remix.

I'm not sure what you mean by "depending on internals"?

I don't think we'll extend relative="path" to redirect because in hindsight after we shipped that API we realized how easy it would be to do in user-land via something like the above (let to = new URL("../e", window.origin + useLocation().pathname).pathname and <Link to={to} />)

from remix.

"depending on internals" — depending on how the route files are structured, not on the path string itself. As you mentioned I might decide to add routes/a.b.tsx for a different reason, and now the relative links that depended on the current behavior are now broken. It's a brittle system, and people are likely using it (if ever) without knowing it's going to break that way.

So that's why I asked "is anyone happy with how relative paths resolve today?"

Backward compatibility aside, making the public user-facing API more intuitive and unified between server and client feels like a happy path (pun intended) for everyone.

from remix.

I wouldn't consider those internals - since you define the route hierarchy.

Your described issue goes both ways - relative paths (as well as absolute paths) are always brittle if you alter your URLs.

The relative routing is currently unified - all routes are relative to the route hierarchy which is a core feature of v6 and nested routing (https://reactrouter.com/en/main/start/overview#relative-links). It's only the opt-in path=relative behavior that is not unified in redirect, and will likely remain as such for the reason explained above.

from remix.