Scoped/Nested Memory Routers

[auaustorg-ms]

I recently saw this: https://remix.run/blog/open-development
and was hoping a proposal will help get traction on the proposed changes in this PR: #9112

I originally made this PR in July, but have not had much traction from the maintainers of react-router.

The following section is a majority of copy paste from the PR description (please take a look to see all the discussion).

Hello everyone!
My name is Austin and I am a dev on Xbox. I primarily work on Xbox Cloud Gaming. We currently leverage the react-router package and enjoy it.

The Problem

We are looking to upgrade to v6 soon and at the same time we are doing some work around Modals and wanted to leverage a MemoryRouter to control a Modal stack. We thought it would be great to navigate our Modals similar to how we navigate the rest of the site.

Key features include

• navigate between modals while passing data
• pop a modal
• push a modal
• clear the stack
• animated transitions, etc
• control the BrowserRouter from within a modal

Our desired features led us back to react-router. We did not want to re-invent the wheel and thought something like a MemoryRouter would be perfect because we wanted our Modal routing system to not be exposed to the Browser. You cannot deep link into a modal, so MemoryRouter made the most sense. It is just meant to be used for in-memory navigation, exactly the purpose of <MemoryRouter>.

So with that in mind, we went looking around to answer the question "Can you have a MemoryRouter inside of a BrowserRouter?". We ended up finding issues like the following:
#9109
#8817
#7375

The Solution

We realized it is not possible to nest Routers in v6 and it was a bummer. After looking through the react-router code, we came to the conclusion that is is definitely possible to enable having nested MemoryRouter's inside of other Routers. So here we are, with a PR (#9112) that enables nesting MemoryRouter's.

Example Usage:

import {
  BrowserRouter,
  Routes,
  Route,
  Outlet,
  Link,
  createScopedMemoryRouterEnvironment,
} from "react-router-dom";

const {
  MemoryRouter: ScopedMemoryRouter,
  Routes: ScopedRoutes,
  Route: ScopedRoute,
  useNavigate: useScopedNavigate,
  Link: ScopedLink,
} = createScopedMemoryRouterEnvironment();

function ModalRouter() {
  return (
    <ScopedMemoryRouter initialEntries={["/"]}>
      <ScopedRoutes>
        <ScopedRoute path="/" element={<FirstModal />} />
        <ScopedRoute path="second" element={<SecondModal />} />
        <ScopedRoute path="third" element={<ThirdModal />} />
      </ScopedRoutes>
    </ScopedMemoryRouter>
  );
}

function SecondModal() {
  const navigate = useScopedNavigate();
  return (
    <div className="baseModal">
      <div className="modalContents">
        <h1>Second Modal</h1>
        <ScopedLink to="/third">Go to third modal</ScopedLink>
        <button onClick={() => navigate(-1)}>Go back</button>
        <Link to="/">Go home</Link>
      </div>
    </div>
  );
}

function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Layout />}>
          <Route index element={<Home />} />
          <Route path="about" element={<About />} />
          <Route path="dashboard" element={<Dashboard />} />
          <Route path="modals" element={<ModalRouter />} />
          <Route path="*" element={<NoMatch />} />
        </Route>
      </Routes>
    </div>
  );
}

You can see this example under the new examples/scoped-memory-router demo.

How it works

There is a new method exported called createScopedMemoryRouterEnvironment which returns the various components / hooks needed for a scoped memory router.

This function does not return things like BrowserRouter since it does not make sense to have nested BrowserRouter's.
It works by making almost all components / hooks into create methods. Instead of having useLocation use the default context, we replaced it with a createLocationHook that is passed a context. We then use the default context for the default useLocation export, but it then allows us to create a new useLocation hook inside of createScopedMemoryRouterEnvironment.

This creator pattern was taken from react-redux as seen in their useSelector implementation.

We've leveraged react-redux createSelectorHook before and had a great time working with that pattern. We believe this pattern can also be used in react-router and have proved it out in this PR. These proposed changes would resolve issues like:
#9109
#8817
#7375

FAQ

Why do you need to create unique contexts?

The implementation in this PR allows navigation of different routers from any level of the application by allowing MemoryRouters to have distinct contexts.

The createScopedMemoryRouterEnvironment call returns scoped hooks that allow you to perform actions within the scoped MemoryRouter. You can see this at play in the example here:

const {
  MemoryRouter: ScopedMemoryRouter,
  Routes: ScopedRoutes,
  Route: ScopedRoute,
  useNavigate: useScopedNavigate,
  Link: ScopedLink,
} = createScopedMemoryRouterEnvironment();

If you'd like to navigate the root BrowserRouter you'd use the regularly imported hooks from the lib and if you're navigating within the scoped memory router I'd anticipate you'd run this in a module in user-land code and re-export out these generated values, i.e.:

src/embedded-application/scoped-react-router.ts

export const {
  MemoryRouter,
  Routes,
  Route,
  useNavigate,
  Link,
  ...
} = createScopedMemoryRouterEnvironment();

src/embedded-application/component/Foo.tsx

import { useNavigate as useScopedNavigate } from '../scoped-react-router';
import { useNavigate } from 'react-router';

This allows us to navigate within the scoped Memory Router, but also navigate at the Browser Router level if needed.
Cheers!

[timdorr]

I wonder if this can be done more easily now that we have the data router concepts in 6.4. In particular, if this could be done without introducing a new API entrypoint and having to export/import a bunch of component and function instances.

For instance, you could have something like this:

const mainRouter = createBrowserRouter(mainRoutes)
const modalRouter = createMemoryRouter(modalRoutes)

render(
  <RouterProvider router={mainRouter}>
    <RouterProvider router={modalRouter} />
  </RouterProvider>
)

That wouldn't all be in one file, but spread out throughout the component tree. I'm just using this example to display the general structure and sources of things.

In one of your modal's components that's located at the root route for modalRouter, you could do this:

function Something() {
  const router = useRouterContext() // This is modalRouter from above
  const navigate = router.parent.navigate // router.parent is mainRouter

  return (
    <div>
      <Link to="..">Go back</Link> {/* This would go up above the modal to the leaf route in mainRouter */}
      <button onClick={() => navigate('/profile')}>Go to your profile</button>
    </div>
  )
}

The only new API here is useRouterContext, just to get the scope-local router instance from RouterProvider. That has a parent property to allow access to whatever context is above it. Everything else is the same.

[yan00000000]

Hello,
i like the idea proposed by @timdorr
any updates or plans on this ?

[brophdawg11]

Original PR for this idea: #9112

[natoszme]

Hi there! Are there any updates on this feature?
Thanks for the PR!

[nick]

Would love to see support for a nested memory router. I have a 'sidebar' app that is independent of the 'main' app and allows the user to do things such as customize the app theme, fonts etc. It's like a mini-app within the main app, and needs to have it's own set of routes. Right now I'm using this workaround which seems to be working fine.

[agurtovoy]

FWIW, here's a detailed walk through the "modal router" pattern in v5: https://charlypoly.com/publications/react-memory-router-pattern.

[javadkh2]

I had this issue and noticed that react-router already exports the context objects with the UNSAFE_ prefix. With some debugging, I found there are three context objects used in the components and hooks. So, I created a scoped context by setting them to default values:

<UNSAFE_RouteContext.Provider
  value={{
    outlet: null,
    matches: [],
    isDataRoute: false,
  }}
>
  <UNSAFE_NavigationContext.Provider value={null}>
    <UNSAFE_LocationContext.Provider value={null}>
      {children}
    </UNSAFE_LocationContext.Provider>
  </UNSAFE_NavigationContext.Provider>
</UNSAFE_RouteContext.Provider>;

I created a new provider called ScopedRouterProvider and a component that allows rendering components in the parent context.

Then, I used it like this:

<ScopedRouterProvider>
  <MemoryRouter>
    <Routes>
      <Route path="/modal/1" element={<Modal />} />
      <Route path="/" element={<Page />} />
    </Routes>
  </MemoryRouter>
</ScopedRouterProvider>;

In the modal, when I needed to use the root Navigate component, I used the RenderInParentRouterContext component:

<RenderInParentRouterContext>
   <Navigate to="/about" />
</RenderInParentRouterContext>

I didn't find an easy way to use hooks with different parent/nested context in one component. Instead, I created a new component and wrapped it with RenderInParentRouterContext.

I haven't tested this for all possible scenarios, but it works in my project.

You can have a look here:
ScopedRouterProvider.

[paralin]

Is there any non-hack way to nest Routers today? I have an app where I want to use a MemoryRouter nested within a normal router to manage a sub-window (like iframe) within the application which has its own path.

[jamesmarrs]

hey @paralin, thought maybe this comment could help you, but i think you are already on the right track!

#7375 (comment)

[skipjack]

I mean... I'm not sure what you mean by "non-hack" but we're taking this approach (for the exact same use case you described) and it's working perfectly so far:

import React, { useLayoutEffect, useRef } from 'react'
import { createRoot } from 'react-dom/client'
import { Provider } from 'react-redux'
import store from '../store'

/**
 * This is just a temporary solution to allow the nested `MemoryRouter` until
 * `react-router` supports it out of the box.
 *
 * @see https://github.com/remix-run/react-router/pull/9112#issuecomment-1241077187
 */
const MemoryRouterContextWrapper = ({
  children,
}: {
  children: React.ReactNode
}) => {
  const ref = useRef<React.ElementRef<'div'>>(null)

  useLayoutEffect(() => {
    const root = ref.current && createRoot(ref.current)

    root?.render(
      <Provider store={store}>
        <React.Suspense fallback="...">{children}</React.Suspense>
      </Provider>
    )

    return () => {
      setTimeout(() => {
        root?.unmount()
      })
    }
  }, [])

  return (
    <div
      ref={ref}
      style={{
        width: '100%',
        height: '100%',
        overflow: 'hidden',
      }}
    />
  )
}

export default MemoryRouterContextWrapper

Obviously Provider and store wouldn't be necessary if you aren't using redux but you get the point. Then we use it like so...

<MemoryRouterContextWrapper>
  <MemoryRouter>
    <span>xyz...</span>
    <Routes>
      <Route ... />
      <Route ... />
      <Route ... />
    </Routes>
  </MemoryRouter>
</MemoryRouterContextWrapper>

Just to be clear though, basically any approach will be a "hack" until it's supported out of the box (which is the main discussion on this thread). The downside of what I propose above is that you have to keep MemoryRouterContextWrapper in sync with whatever your top-level component is doing context-wise (if you want your "sub-window" to have all the same context available). There are also likely some performance implications and maybe other gotchas I'm not thinking of yet 😅

[paralin]

Unfortunately creating a new react root is not a possible solution in my use case. I've temporarily solved it by just deleting the check for overriding the route provider in react-router, and everything works fine. I wonder why the check / prevention of overriding the router provider for a component subtree is there. It works perfectly fine without.

[SaadBazaz]

This did not work for me. The context was lost and routing broke.

This solution worked, though: #7375 (comment)

[rossipedia]

👋 Love this, but I'd go one step further and add support for nested hash routers as well.

There's probably a bunch of use-cases for having an embedded Hash Router on a remix page that would allow for highly dynamic yet content-addressable and linkable experiences.

For posterity, this is what I mentioned in Discord about it:

I'd love to see nested hash routers too
Since hashes are purely client side, they should (in theory) be usable along side remix routes without conflicting, since the hash doesn't contribute to remix's route resolution
And you could still end up with shareable URLs for sub resources

[cqueiroz-ciandt]

Great! I'm also looking to use HashRouters.

[chrisjlee]

Interested in this as well #9601 is dead ?

[jamesmarrs]

@chrisjlee haven't been keeping up to date on the repo as of recent, but i believe this is dead.

Im still so bummed they took this functionality away. Using a MemoryRouter to implement component composition on a smaller scale for decoupled complex components was so useful when you didn't want to change the URL!

I feel like i lost so much functionality upgrading : (

If you currently have a lot of complex components composed of MemoryRouters in a BrowserRouter, I can give you tips on how to migrate it

[chrisjlee]

Yeah would love to be pointed in the right direction

[jamesmarrs]

Theres a few different routes that you can take depending on the urgency, the time you have, and how big of a project you are trying to migrate.

Personally on only use react-router-dom for strictly routing, i dont think i use any of the new remix functionality (maybe a hook or two).

So your use case could be very different than mine. BUT...

To get things working in an existing project, i talked about forking the library here and just allowing the other routers (in my case MemoryRouters) to 'just work' inside of a browser router. this comes with a few cons:

1. Need to keep track of what context your in. (to ensure you are navigating to the correct url if you have to link to some other part of the application)
2. Dont get the latest updates from the react-router team.

v6 is composed of a singular routes file (with all routes known ahead of time), with all routes defined ahead of time to ensure some of the new hooks and features work.
I ended up giving up on the nested routers feature to be released and went this direction the more time i had to devote to my bigger projects. I converted all my MemoryRouters into browser router routes utilizing the context. This is not ideal for me, as i do not want some of this functionality to be exposed to the history stack, but you really dont have a choice if you want to keep up to date with this project. Lots of my universal components were built on top of react-router to orchestrate component composition and to not re-invent the wheel when it came to modals, tabs, drawers, etc. So i just bit the bullet, but I am still hoping one day they support this so i can go back and decouple my complex components with a <MemoryRouter /> and not have so much logic stuffed into them that react-router-dom just took care of by default out of the box. It really took away a lot of good functionality from this library : (

[chrisyalamov]

Any update on if this is considered for v7? I saw it mentioned in the Discord server (https://discord.com/channels/770287896669978684/940264701785423992/1247623644834824495) but there hasn't been much discussion around it