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.

[chrisl8888]

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

[chrisl8888]

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

[ryanflorence]

Hey folks, we really appreciate all the conversation here. We've noodled on allowing this for a long time, but we've decided we won't be adding support for this.

I think we have a pretty good reason. It's not a technical limitation but an opinion worth reading if you were invested here.

Don't break the back button

Over a decade ago websites started getting more dynamic and the "web app" became a new category. As somebody who lived through this period it was awesome but was also very frustrating. Every day I'd scream into my non-retina pixelated PowerBook Pro G4

Don't break the back button!

I'd click something, the UI would change, I'd click the back button, and I'd be somewhere completely different than where I was before. This is the only reason we started this project in the first place.

Not breaking the back button is kind of the only feature of React Router. No other feature exists independent of it. What bundles need to load if they refresh the page and hit the back button? What data do we need if they hit the back button? What should they see if they hit the back button after a form submission?

And of course, what UI should they see when they click the back button.

By enabling nested routers, particularly memory routers inside a browser router, we would be knowingly and intentionally allowing your app to break the back button.

What is memory router for

MemoryRouter was created for non-browser environments like react native and testing, but we dropped react-native support in v7 so it's really just for testing.

What you're looking for is useState and a switch for most use cases discussed here. But even then, I'd encourage you to use useSearchParams or location.state for modals and multi-step workflows so that users can click the back button and see what they expect.

Again, thanks for all the feedback here, we sincerely appreciate the time people put into helping us make our software useful. I hope you can understand our stance here. Don't break the back button! 😅

[jamesmarrs]

Hey @ryanflorence! Thanks for the comment. I have really enjoyed using this library over the years, so big shout out to the team!

This issue isn't applicable for me anymore, but I just wanted to touch on a few things.

Don't break the back button!

From a singularity principle of this being a routing library at its core, I completely understand that. I think the pain point was really introduced when nested routing was allowed, and then suddenly not allowed. Some of my large apps were very reliant on react-router and all it had to offer at the time.

What you're looking for is useState and a switch for most use cases discussed here.

You are correct, this can be achieved with probably not much custom code. Personally it felt silly to reinvent the wheel when the react-router team created a routing paradigm that worked really well for organizing and maintaining code no matter the routing context. I built "router components" like modals, tabs, workflows, etc, that utilized the react-router api, and they all 'just worked' out of the box. So i didn't need to maintain different solutions for browser contexts and memory contexts. Which I thought was really cool!

MemoryRouter was created for non-browser environments like react native and testing

I completely understand this intention, but it was a great tool for building complex components back in the day. It could orchestrate your entire component, just like it orchestrated your entire application. So it felt natural to do.

Great example is a persistent sidebar within some layout that needed tabs and modals decoupled from the browser context and would not change the history. It was so easy to use the same components built on top of the react-router api. It could manage it all very well no matter the routing context.

My apps that utilized the react-router library probably took the utilization too far. It was then too dependent on breaking changes, which caused quite a debacle when upgrading and staying up to date with some of the later changes.

---

I understand your decisions though, especially with modern solutions like remix and next and the way the work with react 19. So i tried to help others at a high level in the same predicament.

It was just a painful time for how fast the library was moving if your apps integrated react-router heavily.

Cheers!