Move relative routing logic into @remix-run/router

[brophdawg11]

Stemmed from #7634 (comment)

Relative routing logic is currently handled by react-router and it always hands off a resolved path to router.navigate. This is because the relative routing logic needs to know the current location (not just URL, but the call-site contextual Route). But this does not need to be the case since the router knows the route tree, so it could accept a source routeId as an option and all relative routing could happen inside the router.

This would allow for slimmer UI-layers (react-router-dom, remix-router-preact, remix-router-vue, etc.)

The proposed API would probably be to add a new optional routeId to NavigateOptions:

let routes = [{
  id: 'root',
  path: '/', 
  children: [{
    id: 'a',
    path: 'a',
  }, {
    id: 'b',
    path: 'b', 
  }]
}]'

// Start at the root Route
let router = createBrowserRouter(routes);

// Absolute navigation since no sourceRouteId is passed
router.navigate('/a')

// Relative navigation from inside the A <Route>
router.navigate('../b', { fromRouteId: 'a' })

This would also be implemented for fetchers, as they already require an incoming routeId so they can bubble errors to appropriate error boundaries.

A couple open-questions since I haven't yet thought about this too deeply:

• non-data-routers would still need to do this in the UI layer hooks/components since they don't go through the router and use history directly. For v6, would we continue resolving relative paths in useNavigate and skip passing sourceRouteId until v7? It could be used for external navigations only. Or, if we were ok with introducing code forks we could potentially do this for data-router usages only.
• Users would likely need a way to get the current routeId, something along the lines of what [Feature]: Have ability to read route id from the nearest route context #9543 was looking for (useRouteId maybe?)
• If we do this we should also be able to stabilize the useNavigate return value
• While we're in here, we should add basename support for fetchers. Basically any time we resolve a path we should support basename + relative routing (navigations, fetches, redirects)

[ryanflorence]

But Why?

I'd add the whole point of this is that the identity of navigate would never change, avoiding a whole host of useEffect issues in React.

let navigate = useNavigate();
useEffect(() => {
  // we're good
}, [navigate]);

Before the data routers, the identity had to change whenever the location changed because the state used for relative navigation (navigate("..")) lived in the react tree (location).

[brophdawg11]

Related issue - fetcher should respect basename: #9711

[brophdawg11]

also implemented in #10336

[brophdawg11]

This is implemented in #10336 and should be released in 6.11.0