Inserting React nodes between the Router's providers and the Router itself when using Data APIs pattern

[ernestostifano]

Hi guys, I was peeking into your source-code trying to figure out how to cover a particular use case of a project I am working on.

During that process, I found your multiple warnings encouraging to share any particular needs we might have in order to eventually improve the library (I like your approach).

So, this is the situation (I will try to skip details that are not relevant to the case).

• We create small/separate UI units and export them as Route Objects:

const node1 = {
    element: (
        <UIUnit/>
    ),
    errorElement: <Error/>,
    children: [
        {
            path: PATHS.NODE1.HOME,
            element: <Home/>
        },
        {
            path: PATHS.NODE1.DASHBOARD,
            element: <Dashboard/>
        },
        {
            element: <Settings/>,
            children: [
                {
                    path: PATHS.NODE1.PREFERENCES,
                    element: <Preferences/>
                }
            ]
        }
    ]
};

• We import those UI units, and we mix them together to obtain bigger Route Objects that we call "layouts", which are just different combinations of the smaller UI units, providing different UXs for the same application:

const layout1 = {
    element: (
        <Root/>
    ),
    errorElement: <Error/>,
    children: [
        node1,
        node2,
        {
            element: <SubArea/>,
            children: [
                node3,
                node4
            ]
        }
    ]
};

• Finally, we import all the layouts into the actual application and create ready to use routers for each one of them:

const router1 = createBrowserRouter([layout1]);
const router2 = createBrowserRouter([layout2]);
const router3 = createBrowserRouter([layout3]);

• The whole purpose of this is to be able to switch between layouts dynamically at runtime, so, for example, some types of users will see a dedicated layout, with a different navigation experience.

const App = () => {
    const router = useMemo(() => {
        // LOGIC TO SELECT ONE OF THE ABOVE ROUTERS
    }, []);

    return (
        <AppContainer router={router}/>
    );
};

• This is pseudocode of the AppContainer component:

const AppContainer = ({router}) => {
    return (
        <AppProvider1>
            <AppProvider2>
                <AppProvider3>
                    <ApplicationManager>
                        <RouterProvider router={router}/>
                    </ApplicationManager>
                </AppProvider3>
            </AppProvider2>
        </AppProvider1>
    );
};

The Problems/Doubts

• The ApplicationManager component needs to have access to all the application's providers to make some high-level operations/calculations. We would also like to keep it always mounted. With the above configuration it does not have access to the navigation context.
• Consider that the children of ApplicationManager are rendered conditionally based on the application state (mainly after loading some core required resources).
• Obviously it would be more efficient to call createBrowserRouter only for the currently selected layout, but there are no documented examples about calling it inside a useMemo, for example.
• Ideally, we would like to do something like this:

const AppContainer = ({router}) => {
    return (
        <AppProvider1>
            <AppProvider2>
                <AppProvider3>
                    <RouterProvider> // PROVIDERS HERE
                        <ApplicationManager> // CUSTOM STUFF IN THE MIDDLE
                            <Router router={router}/> // ROUTER HERE
                        </ApplicationManager>
                    </RouterProvider>
                </AppProvider3>
            </AppProvider2>
        </AppProvider1>
    );
};

• As explained above, the internal Router would be rendered conditionally with a different router/layout based on some application state.
• An alternative could be:

const AppContainer = ({router}) => {
    return (
        <AppProvider1>
            <AppProvider2>
                <AppProvider3>
                    <RouterProvider router={router}>
                      <ApplicationManager/>
                    </RouterProvider>
                </AppProvider3>
            </AppProvider2>
        </AppProvider1>
    );
};

• So, ApplicationManager would be instantiated between the providers and the router internally. Should work, but the first alternative feels better, less opinionated.
• With the old Routers (EX. BrowserRouter) this was possible, because routes are separated from the router provider, so this feels like a limitation.
• I do not know the implementation details, but since we have access to the router instance, and I see it does not only contain the routes, but the actual state, isn't there or couldn't there be a changeRoutes method or similar in order to change all the routes (layout) seamlessly, without loosing the navigation state? (Maybe this is unnecessary) (trying to consider comments from Conditionally rendering Routes with `createBrowserRouter` #10223).
• What worries me about the above point is that I see that RouterProvider component subscribes to the router instance, but it never unsubscribes (not even after unmounting). So, would it be correct if I unmount the whole navigation and mount it again to change the layout? (This should be absolutely allowed, because it is perfectly aligned with how React works).

Would like to hear some opinions in order to use the library in the most reliable and efficient way.
Would also be available to help if needed! Even documentation wise.

Thank you very much.

[ernestostifano]

Hi @brophdawg11, I have read your comments on #10223, and I would really appreciate your opinion about this topic. I would be really happy to propose a PR, if needed. I don't think that our case can be defined as "conditional routing", because all of our layouts are "entire route trees" that are completely "defined up-front". Really think that separating the router provider from the actual data router could make the interface a lot more flexible.

[brophdawg11]

Thanks for the detailed explanation @ernestostifano 🙌

providing different UXs for the same application

Can you elaborate a bit on what types of differences these various layouts have? Do they just change theming and layouts? Do they share URLs or provide different sets of URLs? Maybe even a few screenshots if that's possible would help me understand the end-goal UX you're looking for. Hopefully with a bit more information I can try to provide some guidance on the best way to accomplish that in a RouterProvider world.

Creating 3 separate routers is definitely a bit of an anti-pattern. Consider the router as a more powerful version of history from pre-6.4. There's only one URL/window.history and the router is tightly coupled to that - so there can only be one router.

The concept of changing the route tree at runtime is understood and something we hope to make better in RouterProvider use-cases in the future for use cases like this and MFE and the like.

[ernestostifano]

Hi @brophdawg11, thank you very much for your response and sorry for my delay.

Let's split the issue in two parts:

1: Accessing the navigation context outside routes

In react-router, under lib/components.tsx the RouterProvider component has the following JSX structure:

<>
  <DataRouterContext.Provider value={dataRouterContext}>
    <DataRouterStateContext.Provider value={state}>
      <Router
        basename={router.basename}
        location={router.state.location}
        navigationType={router.state.historyAction}
        navigator={navigator}
      >
        {router.state.initialized ? (
          <DataRoutes routes={router.routes} state={state} />
        ) : (
          fallbackElement
        )}
      </Router>
    </DataRouterStateContext.Provider>
  </DataRouterContext.Provider>
  {null}
</>

So it is impossible to insert anything between your two providers and the routes themselves. Please also note that the routes are conditionally rendered.

Our application has the following structure:

<UDSProvider>
    <I18nextProvider i18n={i18n}>
        <ThemeStore themes={themes} defaultTheme={defaultTheme}>
            <PromptsServiceStore>
                <NotificationsServiceStore>
                    <AuthManager />
                    <LocalizationManager />

                    <NotificationsServiceManager />
                    <PromptsServiceManager />

                    <ApplicationManager loading={loading}>
                        <RouterProvider router={router} />
                    </ApplicationManager>
                </NotificationsServiceStore>
            </PromptsServiceStore>
        </ThemeStore>
    </I18nextProvider>
</UDSProvider>

Where router is currently defined as follows:

const router = useMemo(() => {
    return createBrowserRouter([
        {
            element: <NavigationManager />,
            children: layout.content
        }
    ]);
}, [layout]);

I know this is not ideal, in fact, this belongs to the second part of the issue. For the first part, it is just about accessing the navigation context. For now, I just wanted to show this ugly trick to allow NavigationManager to access the context.

We need NavigationManager and ApplicationManager specifically to be inside DataRouterContext to be able to interact with it (useLocation, useNavigate, etc.). But those components, and all other components in the above structure, that are outside of the RouterProvider, must be always mounted and live outside of the routes in general. They handle very critical core logic at very low levels (platform core data fetching, authentication, fonts loading and injection, stylesheets management, etc.).

It would be very, very limiting to have RouterProvider as the main component (root) of our app and everything else inside a route object (though, it seems to have been design with that in mind).

With the old interface, it was possible to place the navigation provider and the routes separately. With the new interface, it is not possible.

One possible solution would be to make RouterProvider accept a children that will always be rendered (not conditionally), so it will behave more as a standard provider. Then DataRoutes could be exported separately. When no children are passed, DataRoutes would be rendered internally to not introduce breaking changes.

Our app would look something like this:

<UDSProvider>
    <I18nextProvider i18n={i18n}>
        <ThemeStore themes={themes} defaultTheme={defaultTheme}>
            <RouterProvider router={router}> // *** PROVIDER HERE ***
                <PromptsServiceStore>
                    <NotificationsServiceStore>
                        <AuthManager />
                        <LocalizationManager />
                        <NavigationManager />

                        <NotificationsServiceManager />
                        <PromptsServiceManager />

                        <ApplicationManager loading={loading}>
                            <DataRoutes /> // *** ROUTES HERE ***
                        </ApplicationManager>
                    </NotificationsServiceStore>
                </PromptsServiceStore>
            </RouterProvider>
        </ThemeStore>
    </I18nextProvider>
</UDSProvider>

So DataRoutes would be kind of an Outlet. I already have a code proposal for this (will share a part in a separate comment).

2: Dynamically changing routes (layouts)

Since we develop each part of the application in isolation and in multiple variants (full page, multiple sized widgets, pills, etc.), we are able to compose different "layouts" by re-arranging or replacing parts/variants. A layout could display different versions of the UI (with the same URL) or even have more/less areas with different URLs.

Immagine one operator gets a fully detailed user administration experience (multiple tabs with users, groups and roles management), but other operator gets only one page with stats and some shortcuts (under the same URL).

Now, I know this could be handled inside that specific area and not at a routing level, but since the entire app can change substantially between users, the most clean way is to map layouts.

This is already working, when statically passing the layout. The next step for us is to switch between layouts dynamically. This will most likely happen at loading time, only once and with the current implementation it should work.

Creating 3 separate routers is definitely a bit of an anti-pattern. Consider the router as a more powerful version of history from pre-6.4. There's only one URL/window.history and the router is tightly coupled to that - so there can only be one router.

I agree with you, in fact that is the problem. We would like to have a single navigation state, but being able to change the routes (without loosing the state, this is very important). Pretty much like changing the JSX structure inside an app using the old routers.

My biggest concern right now is that there could be issues by un-mounting and mounting again the current RouterProvider does it have any side-effects? Does it cleanup everything on un-mount? Are there risks of memory leaks or other issues?

That should not be an issue after separating the providers from the routes (so the providers remain always mounted and the state persists). The only remaining point would be, passing a different router object after initializing the previous one would work? Maybe we just take the new routes, preserving the current state...

I would be very happy to help!

Thank you very much for your time.

[brophdawg11]

So it is impossible to insert anything between your two providers and the routes themselves. Please also note that the routes are conditionally rendered.

It is not impossible - you can do this via a pathless layout route.

So DataRoutes would be kind of an Outlet

This is exactly what a pathless layout route gives you! Can you elaborate on why something like this wouldn't work for you?

let router = createBrowserRouter([{
  path: '/',
  Component() {
    return (
      <UDSProvider>
        <I18nextProvider i18n={i18n}>
          {/* ... other context providers ... */}
          <ApplicationManager>
            <Outlet />
          </ApplicationManager>
        </I18nNextProvider>
      </UDSProvider>
    );
  },
  children: [
    // app routes here
  ],
}]);

function App() {
  return <RouterProvider router={router} />
}

Maybe a minimal reproduction repo of an architecture similar to what you have would be helpful to make sure we're on the same page?

[brophdawg11]

My biggest concern right now is that there could be issues by un-mounting and mounting again the current RouterProvider does it have any side-effects? Does it cleanup everything on un-mount? Are there risks of memory leaks or other issues?

If unmounted, yes <RouterProvider> will clean up properly, and unregister popstate listeners and such.

Is this the reason the above layout route doesn't work? Since unmounting RouterProvider would cause those root context providers to be unmounted as well? Wouldn't that be the case even if you could insert them as children?

Normally I'd just recommend doing a full page reload when switching between apps (since it feels like it corresponds with a switch of the user). But if you need to maintain the single session, it sounds like maybe you want to lift the state from those areas out of the components into a store that can persist beyond an unmount/remount of RouterProvider?

[ernestostifano]

@brophdawg11 this is my proposal (draft): ernestostifano@40a03a8

All tests pass and it should allow placing providers and routes separately without introducing any breaking change. Is not the solution for all problems, but for sure one more step towards the final goal.

This will give more flexibility to devs, at least accessing the contexts.

Usages

import {RouterProvider, DataRoutes} from 'react-router-dom';

function OptionA() {
    return <RouterProvider router={router} />;
}

function OptionB() {
    return (
        <RouterProvider router={router}>
            <SomeComponent1 />
            <SomeComponent2>
                <DataRoutes />
            </SomeComponent2>
        </RouterProvider>
    );
}

Both works!