Best practices for nested settings route

[segersniels]

Imagine a SPA with a settings sheet similar to shadcdn's https://ui.shadcn.com/docs/components/sheet but as a nested route under /settings. With the way that Remix routing works the /settings route targets the root layout at app/root.tsx which removes all content from app/routes/_index.tsx since it's not rendered through an <Outlet /> there.

Now my current solution (which you can see in action here if you press the sliders icon in the sidebar) basically moved my entire page from _index.tsx under app/root.tsx and removed the _index.tsx route entirely. But this feels very counter intuitive that my entire app would be under the root route incl. the actions and loaders associated with the route. Something feels 💩

My DX oriented mind would love a way to keep the root route super basic with just the sidebar and outlet and still have the _index.tsx containing the / route code. Is there a way I can tell a nested route to target a specific outlet? Meaning that I could tell /settings to render in an <Outlet /> of _index.tsx instead of the root.

Another way I could think of was creating a layout route _.tsx with the entire / code and then have a _.settings.tsx with the nested route. But not sure if I'm a fan of that either. Cause what do you even do to handle the index route? Create a dummy _._index.tsx route that just returns null?

What are the usual best practices for UI like this? Or am I approaching this wrong entirely and should I just not use nested routes for something like this.

[segersniels]

Ok thinking about it from a different angle about a project with more than just the root route, having a nested route for something like this wouldn't even work. I guess I have my answer there why something like this shouldn't be a nested route.

[kiliman]

Ok, I updated the example app.

I used the Remix routes config to manually add the panel routes (in this case settings) to the top-level routes. So Remix now sees /home/settings and /about/settings and they both use the same route file.

    remix({
      ignoredRouteFiles: ['**/*'],
      routes: () => {
        const routes = flatRoutes('app');
        addPanel(routes, 'routes/home', 'settings');
        addPanel(routes, 'routes/about', 'settings');
        console.log(routes);
        return routes;
      },
    // snip

function addPanel(routes: any, parentId: string, panel: string) {
  const panelId = `${parentId}/${panel}`;
  routes[panelId] = {
    id: panelId,
    parentId,
    path: panel,
    file: `routes/panels/${panel}.tsx`,
  };
}

<Routes>
  <Route file="root.tsx">
    <Route index file="routes/_index.tsx" />
    <Route path="about" file="routes/about.tsx">
      <Route path="settings" file="routes/panels/settings.tsx" />
    </Route>
    <Route path="home" file="routes/home.tsx">
      <Route path="settings" file="routes/panels/settings.tsx" />
    </Route>
  </Route>
</Routes>

[segersniels]

That's pretty cool. Didn't know you could do that, TIL! Thanks! Is that a common design pattern to do it like that in Remix?

[kiliman]

I don't know about common, but that is why they opened up the routes config so you can support whatever functionality you need.

I updated the example to also let you use the _index route with child routes.

 routes: () => {
        const routes = flatRoutes('app');
        // delete the `index` prop from the index route
        // so we can have nested routes for panels
        routes['routes/_index'].index = false;
        routes['routes/_index'].path = '/';

        addPanel(routes, 'routes/_index', 'settings');
        addPanel(routes, 'routes/about', 'settings');

        console.log(routes);
        return routes;
      },

[kiliman]

I also fixed the issue where the settings panel didn't render properly if you refreshed on the /about/settings route. It was a hydration issue that was fixed using the RC versions of react and react-dom (v19).