Sibling Routes (aka Parallel Routes or Aggregated Routes)

[sergiodxa]

Proposal

Add sibling routes support to Remix and React Router to allow matching multiple routes in the same segment but being independent chunks and with a different data URL.

Background

The proposal #5383 was created to discuss the possible to add some compiler magic to let component define a loader and Remix compiler will generate a route for it and call it together with other loaders (including the route loader) on each route where this component is imported.

After discussing in Discord about this, I came to the conclusion that a simpler and less magical way to achieve a similar result would be to support sibling routes.

The idea would be that any route could have sibling routes that have their unique component, loader, action, error boundary and links, and both the route and its sibling will match the same route segment.

This will allow you to split a UI in different components (a main one plus multiple siblings) and render them together, with their own data loading and mutations.

Use Case

• Keeps components decoupled and promotes reuse
• Let developers have more granularity on the loader and actions for different parts of the UI
• Components and their data dependencies can be quickly modified without modifying other parts of the system
• Having isolated components makes it easier to have separation of concerns and team ownership of specific functionality
• Each sibling could own a form in the UI with its loader and action
• Each sibling could have its own error/catch boundary
• Each sibling could have its own HTTP caching policy, allowing for more usage of HTTP cache even when mixing public and private data

API/Examples

React Router API

In React Router a way to define them could be by using a siblings attribute in any route element:

let routes = createBrowserRouter([
  {
    path: "parent",
    element: <Parent />,
    children: [
      {
        path: "leaf",
        element: <Leaf />,
        async loader() {
          // get leaf data
        },
        siblings: {
          sibling: {
            element: <Sibling />,
            async loader() {
              // get sibling data
            }
          },
        },
      },
    ],
  },
]);

Note that siblings is not an array of routes but an object, this is because each sibling must have a name and the name must be unique between all siblings.

A sibling is an object similar to any other route except it doesn't include a path or children attribute.

The createBrowserRouter function should update its type to ensure the first list of routes can't have siblings, so if right now there's a Route interface defining what route properties can be set, then there should be a RouteWithSiblings interface that extends Route and adds the siblings attribute.

interface Route {
  // other properties
  children: RouteWithSiblings[];
}

interface RouteWithSiblings extends Route {
  siblings: Record<string, Route>
}

declare function createBrowserRouter(
  routes: Route[]
): BrowserRouter;

This should ensure that routes without a parent can't have siblings, because if you did it the siblings would never be rendered.

Remix File Convention

I propose using @ as a delimiter for sibling routes in Remix, for example in the v1 convention:

routes/parent/leaf.tsx
routes/parent/leaf@sibling.tsx
routes/parent.tsx

Or in the v2 convention:

routes/parent.leaf.tsx
routes/parent.leaf@sibling.tsx
routes/parent.tsx

Both conventions will generate the route /parent/leaf.

Named Outlet

The parent route will have to render an <Outlet /> for the leaf route, and another one with a name for each sibling.

For example, if the parent route renders a three column layout, it could render the leaf route in the middle column and the sibling routes in the left and right columns.

export default function Component() {
  return (
    <ThreeColumnLayout
      left={<Outlet name="left" />}
      main={<Outlet />}
      right={<Outlet name="right" />}
    />
  );
}

This was, it would be possible to build a more complex layout by using siblings, if the layout has multiples leaf routes each one could provide a different left and right sibling.

routes/dashboard.articles.tsx
routes/dashboard.articles@left.tsx
routes/dashboard.articles@right.tsx
routes/dashboard.users.tsx
routes/dashboard.users@left.tsx
routes/dashboard.users@right.tsx
routes/dashboard.tsx

These route files would generate the following URLs:

• /admin
• /admin/users
• /admin/articles

To give give a more real-world example the following image is a screenshot of Daffy's dashboard.

As you can see, we have multiple nested routes, but the middle and right columns are part of the same route, we had to use a trick with the handle export and useMatches to let the parent route render the right sidebar in the layout.

By using sibling routes we could have a much simpler implementation by moving the right sidebar to a sibling route.

We could take this a step further and split the sidebar in multiple sibling routes, one for each widget in the sidebar to be a route by itself with its data.

If an Outlet is rendered with a name for a sibling route that doesn't exist, it should render null. By doing this we can have a more flexible layout that can be rendered in different ways depending on the sibling routes that exist.

For example the Home Leaf Route could have the siblings mentioned on the image, but a different leaf route could have a different set of siblings.

The app layout route will only need to know where to render every sibling, it doesn't need to know what siblings exist so no all leaf routes needs to have the same siblings.

Matches

The useMatches hook would also need to be updated to support siblings, I think the simplest way is to follow a similar pattern to the RR API and add a siblings record to the matches object.

let matches = useMatches();
// get the sibling of the latest match
let { left, right } = matches.at(-1).siblings;

The type definition would be something similar to:

interface Match { ... } // current definition

interface MatchWithSiblings extends Match {
  siblings: Record<string, Match>
}

The return value of useMatches will be MatchWithSiblings, and siblings are simple Match objects meaning they don't have a siblings property.

useRouteLoaderData

A sibling route data should be available through this hook by using the route ID as any other route.

let left = useRouteLoaderData("routes/parent/leaf@left");
let right = useRouteLoaderData("routes/parent/leaf@right");

In this case the route ID of a sibling route will include the @sibling-name part at the end.

Reusability

If you want to use the same component as a sibling in multiple leaf routes you could use a simple re-export to avoid duplicating the code.

// routes/parent.leaf-1@sibling.tsx
export async function loader() {
  /* code */
}
export default function Component() {
  /* code */
}

// routes/parent.leaf-2@sibling.tsx
export { loader, default } from "~/routes/parent.leaf-1@sibling";

You could even move the definition outside routes.

// components/widget.tsx
export async function loader() {
  /* code */
}
export default function Component() {
  /* code */
}

// routes/parent.leaf-1@sibling.tsx
export { loader, default } from "~/components/widget";

// routes/parent.leaf-2@sibling.tsx
export { loader, default } from "~/components/widget";

This way you can treat the sibling route as a normal component as the #5383 proposal suggests, but there's no magic to convert it to a route.

While this is more manual work than the other proposal, it's more obvious what's happening without being magic.

Data URLs

The data URL for a sibling route will follow the same conventions used by Remix already.

GET /parent/leaf?_data=routes/parent/leaf@sibling
POST /parent/leaf?_data=routes/parent/leaf@sibling

This will allows sibling routes to set Cache-Control on the loader response and get them cached individually. For the Daffy example, the "Make a Donation Sibling Route" that has a search form, could submit a GET request to the route itself, and I could cache the results returned by the loader with a different cache policy than the rest of the routes.

Data Revalidation

Because sibling routes can affect the URL and are affected by changes there, the shouldRevalidate API becomes way more useful.

A sibling route like the "Make a Donation" one could make the search form change the URL search params, because I know the search param used by that route is not used by any other route, those routes could include a shouldRevalidate function that returns false when that search param and only that one change.

Similarly, the "Make a Donation" route could have a shouldRevalidate function that returns false when a different search param changes because they don't affect the results.

This gives the developers using Remix a lot of flexibility to decide what to revalidate and when, by splitting a route in more granular sibling ones.

Links Function

The links function should work as usual, any sibling route can export it and they will be combined with the rest of the links returned by other sibling routes, leaf routes and layout routes.

Headers Function

The sibling routes should be able to export a headers function, that will work as usuall by allowing the route to know the loader, action and parent headers and return a new group of headers.

For non sibling routes, the route will receive a Record<string, Headers> with the headers of all sibling routes.

export let headers: HeadersFunction = ({
  actionHeaders,
  loaderHeaders,
  parentHeaders,
  siblingHeaders
}) => {
  /* code */
}

This way, the leaf route can receive the headers set by its siblings loaders and combine them.

This record of sibling headers will be empty on sibling routes.

Meta Function

This will be similar to Headers Function, the sibling routes can export a meta function and the non-sibling route will combine them.

Siblings in Layout Routes

Layout routes could define their own siblings to let the layout of the layout render them. However, sibling routes can't have nested routes, this means routes/dashboard@sidebar.settings.tsx is not a valid route and remix build should fail.

However this file structure must work:

routes/dashboard.settings.tsx
routes/dashboard.settings@widget.tsx
routes/dashboard.tsx
routes/dashboard@sidebar.tsx

In that case, the routes/dashboard@sidebar route will be rendered by the root route as a sibling of routes/dashboard.

Open questions

• Should, maybe, sibling routes be able to accept nested routes?

Prior Art

• Next.js parallel routes

[edmundhung]

I definitely prefer this approach over #5383.

But I find it somehow confusing to identify the relationship between siblings and the parent when looking at the file paths. My first impression was that the ThreeColumnLayout is deinfed on dashboard.users.tsx and dashboard.articles.tsx instead of dashboard.tsx.

This makes me wonder if it would be cleaner to swap the order you defined the named slot:

routes/dashboard.articles.tsx
routes/dashboard.users.tsx
routes/dashboard.tsx
routes/dashboard@left.articles.tsx
routes/dashboard@left.users.tsx
routes/dashboard@right.articles.tsx
routes/dashboard@right.users.tsx

With this you can identify where the named outlet is (i.e. dashboard.tsx) and support nested routes just like the rest of the route. Imaging defining this as JSX:

<Route path="dashboard">
    <Route path="articles" />
    <Route path="users" />
    <Slot name="left">
        <Route path="articles" />
        <Route path="users" />
    </Slot>
    <Slot name="right">
        <Route path="articles" />
        <Route path="users" />
    </Slot>
</Route>

[kasperpeulen]

I love this. I think it is really elegant how Remix can analyse the entire dependency graph for every route (both static assets and data requirements) either by:

• file system convention
• explicitly writing down this graph as router config

By looking at this graph (in config or on the file system) you can see at one glance, a lot about the structure and complexity of the app.
For example, you can find here directly all your routes and API endpoints.

The direction of #5383 is powerful, but completely breaks this mental model of Remix. Somewhere buried in components lays the definition of API routes. What I love about this proposal is that it feels completely inline with Remix, but just improves the dependency graph to make it endlessly more powerful for complex data requirements. You can now split any route in as many little isolated view/data/mutation modules as you want.

I would only change one thing. I think it might be more natural if the "main sibling" (the one that has a path) would be in charge of placing the "named" siblings. In your proposal the parent of the "siblings" is in charge of placing the child and its siblings, but not every child may have the same named siblings, and I can imagine that the placing of the siblings depend on the specific child.

For example, say, I have two layout routes:

routes/
  _landing.about.tsx
  _landing._index.tsx
  _landing.tsx
  _landing@header.tsx
  _landing@footer.tsx
  _landing@sidebar.tsx
  app._index.tsx
  app.projects.tsx
  app.tsx
  app@nav.tsx
  app@sidebar.tsx

Now in the proposal, the root route (root.tsx) would have to determine where to place the siblings, of both _landing.tsx and app.tsx. But I think it much more natural, if this would happen in _landing.tsx and app.tsx itself:

// ~/routes/_landing.tsx
export default function () {
  return (
    <>
      <Outlet name="header" /> // _landing@header.tsx
      <div className="flex flex-row">
        <Outlet />
        <Outlet name="sidebar" /> _landing@sidebar.tsx
      </div>
      <Outlet name="footer" /> // _landing@footer.tsx
    </>
  );
}

// ~/routes/app.tsx
export default function () {
  return (
    <div className="flex flex-row">
      <Outlet name="nav" /> // app@nav.tsx
      <Outlet />
      <Outlet name="sidebar" /> // app@sidebar.tsx
    </div>
  );
}

Another example:

routes/
  app._index.tsx
  app.projects.tsx
  app.projects@roadmap.tsx
  app.tasks.tsx
  app.tasks@activity.tsx
  app.tsx

Here, only the app.project.tsx file knows where to exactly place the roadmap. And the app.tasks.tsx file knows where to place the activity. It would be very strange if app.tsx would have to decide that.

I think this would also solve @edmundhung concern.

[sergiodxa]

So what you said is instead of using Outlet to render the sibling routes in the layout, it will be the child route itself the one rendering it's siblings inside its UI?

So for example instead of this in the layout:

export default function Component() {
  return (
    <ThreeColumnLayout
      left={<Outlet name="left" />}
      main={<Outlet />}
      right={<Outlet name="right" />}
    />
  );
}

It would be the route rendered in main the one rendering the siblings? In that case it wouldn't be possible to render them in the right column for example, because main wouldn't have access to that, well it will be technically possible by using the handle export to send the elements from main to the layout and render that in right like I do today.

I think it's simpler and gives you more control that layout routes render all children routes including the siblings.

If you want to let the child own it you could add a pathless layout route in the middle just to organize the siblings.

routes/parent._layout.leaf.tsx
routes/parent._layout.leaf@sibling.tsx
routes/parent._layout.tsx              <- this place the leaf and sibling routes in the UI
routes/parent.tsx

That way, you can have a pathless layout route per group of siblings, achieving the same result, and parent doesn't need to know all possible siblings each leaf route will have.

[kasperpeulen]

So what you said is instead of using Outlet to render the sibling routes in the layout, it will be the child route itself the one rendering it's siblings inside its UI?

Exactly.

well it will be technically possible by using the handle export to send the elements from main to the layout and render that in right like I do today.

You could also reuse the <ThreeColumnLayout /> in both children right. I think composing UI components is easy in React. But composing data requirements is kind of hard in Remix, I think I would structure and name your example more from a data/semantical perspective:

// in routes/dashboard.tsx
export default function Dashboard() {
  return (
    <PageLayout
      heading={<Outlet name="heading" />} // routes/dashboard@heading.tsx
      nav={<Outlet name="navigation" />} // routes/dashboard@navigation.tsx
      main={<Outlet />} // routes/dashboard.child.tsx
    />
  );
}

// in routes/dashboard.user.tsx
export default function User() {
  return (
    <ThreeColumnLayout
      left={<Outlet name="profile" />} // routes/dashboard.user@profile.tsx
      main={<Outlet name="stats" />} // routes/dashboard.user@stats.tsx
      right={<Outlet name="friends" />} // routes/dashboard.user@friends.tsx
    />
  );
}

// in routes/dashboard.article.tsx
export default function Article() {
  return (
    <ThreeColumnLayout
      left={<Outlet name="toc" />} // routes/dashboard.article@toc.tsx
      main={<Outlet name="content" />} // routes/dashboard.article@content.tsx
      right={<Outlet name="sidebar" />} // routes/dashboard.article@sidebar.tsx
    />
  );
}

The names of the API routes are also be more instructive if you name it from a data perspective.

[kasperpeulen]

From @jrestall in the other proposal:

Not in favor of compiling to sibling routes as my understanding is they are only one level deep, whereas this proposal is much more powerful since you can nest components to any level and even have data fetching in hooks etc.

@sergiodxa My suggestion would also allow users to nest siblings as deeply as you need, but still keep all siblings files flat:

// in routes/dashboard.article.tsx
export default function Article() {
  return (
    <ThreeColumnLayout
      left={<Outlet name="toc" />} // routes/dashboard.article@toc.tsx
      main={<Outlet name="content" />} // routes/dashboard.article@content.tsx
      right={<Outlet name="sidebar" />} // routes/dashboard.article@sidebar.tsx
    />
  );
}

// in routes/dashboard.article@content.tsx
export default function Article() {
  return (
    <div>
      <article>...</article>
      <Outlet name="subscribe" /> // routes/dashboard.article@subscribe.tsx
      <Outlet name="comments" /> // routes/dashboard.article@comments.tsx
    </div>
  );
}

[ryanflorence]

Jamie Kyle had an idea for slots that reminds me of this:

https://twitter.com/buildsghost/status/1531754246856527872

[sergiodxa]

Ha I remember reading some tweet from Jamie about something similar but I didn't remember where.

Maybe slot could be another name instead of siblings.

[benjamindulau]

What would be the revalidation behavior when a sibling is initiating a mutation (action)?

Here are our use case:

We are currently "remaking" a very large website (B2C) with React Router > 6.4 and all its philosophy and plan to gradually migrate to SSR with Remix.

Some pages can be composed of a lot of small components (derived from an internal Design System). Each of those components declares its own data dependency with GraphQL fragments (colocation principle). Since the page is behind a single route (path) and a single loader, it's really difficult to control atomically each sub-component data loading & mutation behavior, and mainly data revalidation.

ATM, the route loader is responsible of executing all the queries separately for all the page sub-components in parallel (with Apollo Client) while deferring the resulting data promises.

Since everything is behind a single route and thus a single loader, if a sub-component initiates a mutation (so executes the route action), all queries to the GraphQL server would be executed again when React Router revalidates the route loader data even though the sub-component initiating the mutation is the only one concerned by the changing state.

As an example, say we have a sub-component in the page with a "like" button. We would use a fetcher to initiates an action on the route path, and would optimistically update the button to the "liked" state while the server is processing the request. Then we would need to revalidate only the data for this specific sub-component, thus only this sub-component loader function should be executed on revalidation.

How would this happen with this proposal? By implementing a shouldRevalidate function in each sibling so it can say whether or not it is concerned by the mutation? That would be a bit cumbersome.

For now, we have to rely on Apollo Client cache, so when a sub-component is mutating data, the route loader is executed again on revalidation, so all queries for all sub-components are executed again, but since Apollo already has data in cache, it doesn't make new requests to the server... convenient but a bit magical :)

[sergiodxa]

There's a "Data Revalidation" section on the proposal, it would work as it does right now, a route exports a shouldRevalidate function to control the revalidation.

I think for your use case where you have tiny components (e.g. the Like button) with their own data requirements and mutations you will have a better experience using a GraphQL cache client-side directly.

Because this proposal let you split a route in multiple sibling routes, but they need to be static while your Like button can most likely be used multiple times I imagine. Even the #5283 proposal relies on the compiler to know statically what components are used by a route.

What you need to something that can know the queries not statically but at runtime so you can control that with more granular precision, as you used as example to query the data of a Like button in probably a list and only revalidate that specific part of the data.

Basically, I think you need Relay instead, so you have way more control of your data queries, mutations and revalidation.

[rossipedia]

If I'm understanding correctly, the Full Stack Components approach could be applicable as well.

[benjamindulau]

@sergiodxa Components rendered by sibling routes would always be static I think. We never ask the Route to render components directly imported from the design system. The page is always broken down into application level components.

So each sibling route would be in fact static and would render an application level component which itself composes UI with elements from the Design System. This application component is the one exposing its data requirement, actions, etc.

As for now, data requirements are GraphQL fragments, and the route loader is responsible of doing the fetches for each component composing the page with those fragments. And for actions, each application component export its own actions functions, and FormData contains an "intent" field indicating to the route action function which component action function it should forward the action to.

But because the loader can't know which fetcher/Form caused the revalidation, it has to re-execute all the fetches. Well, I think you got the point.

This proposal almost naturally solves this. The only missing part is how can I tell React Router which sibling route is concerned by revalidation.

For now that could be done by implementing a "shouldRevalidate" function in each component, inspecting the form data, and telling whether or not it should be revalidated. But I think this wouldn't be a good DX.

Like you said, this works now because of client side caching library (Apollo Client for us). But I don't like the idea that we have to rely on application level cache (cache is evil). Plus how would this work server side with Remix?

[kentcdodds]

I have a use case for this in my workshop app I'm working on:

This feature would allow me to separate the data loading requirements of those preview tabs from the main route for the page which would help me separate concerns. I'm in favor 👍

[ryanflorence]

I think your bigger problem is CSS Kent.

[ryanflorence]

We had named outlets in early versions of React Router, I think they could be really interesting to bring back, especially with all the data abstractions we have now.

I don't think, however, they are a replacement of #5383.

One major difference is that this expects all child routes of a parent route to share a set of siblings coupled to the parent layout. While this helps get some data more granular and co-located, the abstraction is not a general way to do it: it only works when child routes share a set of "sibling" routes. When they don't share the same set, the parent route gets overly concerned and aware of every child route's siblings. This isn't a critique of the proposal, but the main reason I don't think it's a replacement for the other.

I've been working on a couple other ideas that go along with #5383 that I'll be sharing soon that will hopefully share the problem and scope I'm trying to solve over there.

I think this proposal should be considered independently.

[kasperpeulen]

While this helps get some data more granular and co-located, the abstraction is not a general way to do it: it only works when child routes share a set of "sibling" routes. When they don't share the same set, the parent route gets overly concerned and aware of every child route's siblings.

@sergiodxa I agree with this. It is kind of weird that the parent has to be aware at all the siblings of all its children.

I think this problem would be solved if we would let the child route render its siblings, instead of the parent rendering both the child and the siblings of the child.

See my comment here: #5431 (comment)

[sergiodxa]

I fail to see how that's different that creating a pathless layout route to render the siblings?

For example

root.tsx <- in charge of document, including where to render the sidebar

routes/dashboard.tsx <- dashboard layout
routes/dashboard@sidebar.tsx <- sibling route of dashboard

routes/dashboard._users-layout.tsx <- layout to decide where to render /dashboard/users routes
routes/dashboard._users-layout.users.tsx <- main route
routes/dashboard._users-layout.users@banned-users.tsx <- sibling route
routes/dashboard._users-layout.users@new-users.tsx <- sibling route

routes/dashboard._products-layout.tsx <- layout to decide where to render /dashboard/products routes
routes/dashboard._products-layout.products.tsx <- main route
routes/dashboard._products-layout.products@top.tsx <- sibling route
routes/dashboard._products-layout.products@quick-actions.tsx <- sibling route

I think if the main route was in charge of rendering its sibling it will break how Outlet works.

If we want to go that way we should introduce a <Sibling name="sibling-name" /> component then to be clear this is not a child route, this is a sibling of your route.

[jrestall]

I was thinking what if this was modeled around the URL fragment identifier instead. If it makes any sense and there's interest I can write up a proper proposal.

We could call it Hash Routes since it is modeled on the URL fragment https://www.example.org/team#tweets.

Hash Routes

• We have routing for other parts of the URL, it seems elegant to also support the fragment identifier rather than invent our own routing semantics.
• More intuitive to understand and easier to implement since based on existing web standards #useThePlatform.
• The hash is used to identify fragments of a document so maps nicely to our need to separate a single route into fragments.
• Aligns with existing practices of using anchor links to link to tabs, modals and sections of a page. These are also all things we want to separate into hash routes.
• Fragment identifiers are already understood to not have children or nesting since they are at the end of a URL.
• Would require some changes to the URL format in form posts and data requests since the hash isn't sent to the server by default.

React Router API

const router = createBrowserRouter([
        {
            path: "/",
            element: <Root />,
            loader: rootLoader,
            children: [
                {
                    path: "team",
                    element: <Team />,
                    loader: teamLoader,
                    children: [
                        {
                            path: "#tweets",
                            element: <Tweets />,
                            loader: tweetsLoader,
                            action: tweetsAction
                        },
                    ],
                },
                {
                    path: "#header",
                    element: <Header />
                    loader: headerLoader,
                },
                {
                    path: "#footer",
                    element: <Footer />
                    loader: footerLoader,
                },
            ],
        },
    ]);

Remix API

routes/#header.tsx
routes/#footer.tsx
routes/team/#tweets.tsx
routes/team.tsx

• All children hash routes for each route segment will be loaded in parallel. The hash route's fragment identifier doesn't need to be in the URL for it to render, all will render by default, but if it is then that could trigger behaviour like the lazy loading of that hash route by making it the target.
• Doesn't require a new sibling API and concept.
• APIs like useMatches and useRouteLoaderData don't need to change as they would just return and use the hash route path. e.g. useRouteLoaderData("#tweets") and useMatches would return additional routes with a pathname of #tweets.

Hash Route Loading

Since hash routes are leaf nodes in the route tree, there could be opportunity to lazy load them individually based on viewport, media query or browser idle e.g. no point loading a google maps component and paying API fees if it is below the fold. The API to achieve this would need to be determined.

I'm also curious if hash routes could stream their html directly from the server and not send a JS bundle in Remix by the loader returning html(data) instead of json(data).

If these are possible then this would be a much simpler alternative to a lot of the benefits and use cases for React Server Components.

Hash Route Outlets

The parent route would use Outlets to place the hash routes in the desired positions.

<Outlet href="#tweets" />
<Outlet />

// Conditional Routes
{tweetsEnabled && <Outlet href="#tweets" /> }

 <Link href="#tweets" prefetch="intent" />

• Mirrors the standard use of anchor link tags to link to hash routes. This could be useful for lazy loading hash routes in modals or tabs and would benefit from React Router's existing route loading logic.
• Automatic support for :target css pseudo class to hide and show these routes.
• href prop refers to the URL pattern for the child route path to match and render. id or name might be simpler.

[sergiodxa]

The browsers never sent the hash to the server so it wouldn’t be possible to know on SSR what routes to render

[jrestall]

@sergiodxa all the hash routes for a matching parent route get their loaders called and rendered, so there's no need for the server to have the hash on SSR. The hash in the url could be used client-side though to trigger modals, tabs or lazy loading of the hash route.

[brophdawg11]

This feels like it would introduce the potential for collisions (read "footguns") between hashes defined in the HTML and hashes defined in the routing tree. The former is automatically handled by browsers and currently emulated via <ScrollRestoration>. But the latter would introduce new semantics only known/handled by RR since path:"#hash" wouldn't guarantee the presence of a <div id="hash"> element. In the ideal case where developers always remember to put a hash in the root HTML element of a path:"#hash" route, these would line up. But if they got out of sync you'd have a mismatch between what the browser wants to do versus what RR wants to do.

[Ephem]

Plus one! I've been wanting this for a while now. I think this proposal is better written (and up to date) than mine was back then, but I still wanted to loop in this discussion/suggestion from over in the React Router repo which suggests mostly the same API.

[jamesarosen]

I opened #6234 before reading this. I do think they're quite similar, but I wanted to point out one important difference. As far as I can tell from your proposal, it's not possible for a sibling / slot route to declare a React context provider for the layout's children:

// ~/root.tsx
export default function Root() {
  const { recentlyViewedProducts } = useRouteLoaderData('routes/_index@recentlyViewedProducts')
  return (
    <RecentlyViewedProductsProvider products={recentlyViewedProducts}>
      <Outlet name="recentlyViewedProducts" />
      <Outlet />
    </RecentlyViewedProductsProvider>
  )
}

There are cases where the sibling route is the primary but not sole UI for its data. For these use-cases, the primary benefit of isolating it in a sibling route is being able to optimize HTTP caching; the UI isolation is secondary.

[sergiodxa]

You should be able to do that, sibling routes have route IDs so you can use useRouteLoaderData like you mentioned to access another route data.

You don't even need that extra context, just call useRouteLoaderData("routes/parent/leaf@left") inside routes/parent/leaf route (the main route) and use it, you could even have sibling routes used only for loading data.

Create a sibling route with a loader and a component that renders null, then in the layout use only <Outlet />, even if you don't render the sibling route the route will match and Remix will load the data from its loader, so now you main route can access the sibling loader data and that data can be cached differently than the main route data.

Another thing is that you already have a context with Outlet so you can just do <Outlet context={recentlyViewedProducts} /> instead of adding more context providers.

[jamesarosen]

sibling routes have route IDs so you can use useRouteLoaderData like you mentioned

Great!

You don't even need that extra context

In the trivial case of a context that just re-exports loader data, that's absolutely true! I often build contexts that exposes some data plus mutators or helper functions bound to it.

you already have a context with Outlet so you can just do <Outlet context={recentlyViewedProducts} />

Neat!

[devnomic]

Has the team provided any updates on this, considering it has already been a year? I am kinda in need of a named outlet. Alternatively, functions like createLoader or createAction would be useful, so I can use loader/action in any component.

[tcolinpa]

Does this solve the modal route use case?

Imagine you have a modal that can be opened anywhere, it doesn't matter how nested the route you're in. For example, you have /calendar, /messages, /messages/1... and the modal route would match /calendar/preferences, /messages/preferences, /messages/1/preferences and so on. For to modal to close, you'd just put navigate(-1) and the user would be back right where it first opened.

Ideally, you'd want to keep the layout as well (as backdrop in this case).

Or can this be achieved already?

[kentcdodds]

I know that Ryan, Michael, and Jacob have been working on a revalidation API with RSC that goes more granular than routing. So I'm confident that use case will be handled. Still in the experimentation phase.

[tcolinpa]

Gotcha @kentcdodds. I'm still with @sergiodxa bc I can't wrap my mind on how that would look like. Waiting for RSC support then!

[benjamindulau]

@kentcdodds Well, the project I was referring to is a SPA using React Router so RSC wouldn't help much :)

[kentcdodds]

RSC can be used for SPAs. In that scenario, the "server" is the build server.

[sergiodxa]

The server could also be another function running in a browser, or a service worker, or a web worker.

[manuelbachl]

I actually have a different use case for this feature:

I'm creating a dashboard which aggregates data from 3 different apis. two of them have limits, so I want to call API 1 every minute, API 2 every 5 minutes and API 3 every 30 minutes. to me it seems not possible to achieve that nicely with remix at all. I would so much love to be able to use useRevalidator() for this and just revalidate the child routes every X minutes. I can't find a proper alternate solution for now. For me it seems dirty to trigger client side functions to refetch the apis (especially because of exposure of api keys to the frontend). Maybe I'm missing something - is there any proper solution to retrigger api calls seperately on server side?

[sergiodxa]

You can cache them server-side, e.g. using Redis, then set the ttl of each cache to be 1 minute, 5 minutes and 30 minutes, now you can trigger a revalidation every minute and your loader will keep reading from the cache until it expires. With the additional benefit that you can now share the cache between users if needed.

[ammarriq]

Will the parallel routes feature be included in RR v7?

[sergiodxa]

No, this was never implemented

[ammarriq]

And will never be implemented, right?

[sergiodxa]

Probably, with RSC a sibling route can be a server component that loads its own data and use server actions to mutate so you don't really need this anymore