Defining loaders and actions anywhere in the module graph

[ryanflorence]

tl;dr

• allow loaders/actions anywhere in the module graph
• get great types and dev ergonomics
• would have to cross a line with our bundler we haven't crossed yet

Background

Remix is kind of butthole about where you can define your data needs: route loaders. We do this so that the "right thing is the easy thing". If you load data inside of components you slow down your app so we made that hard.

However, this "right thing" isn't always easy, or at least not as easy as it could be.

With some compiler tricks, we could allow app developers to define data needs anywhere in their app, not just route loaders and we could do it without sacrificing the parallel loading design of Remix.

createLoader

// app/any/where.jsx
import { createLoader } from "@remix-run/react";

let getProject = createLoader(({ params }) => {
  return db.getProject(params.projectId);
});

export function Project() {
  let project = getProject();
  return <div>{project.name}</div>;
}

• TypeScript knows the type of getProject so we get great types w/o app-level generics
• Data dependency is co-located with the component that needs it.

How it could work:

• Bundler finds calls to createLoader in each route's module graph
• Bundler hoists those calls up to the internal route loaders
• Bundler replaces call sites with something like useLoader(someId)
• Runtime calls these data dependencies in parallel with the app's route loader
• Runtime provides the data when resolved
• Client bundles remove the createLoader calls.

Limited to the module scope:

Any calls to createLoader must be in the module scope so that people don't try to pass component state/props to the enclosing function.

export function Project(props) {
  // 🚫 This won't work
  let project = createLoader(() => {
    db.getProject(props.id);
  });

  return <div>{project.name}</div>;
}

This would throw an error at build time that they aren't allowed to create loaders outside of the module scope.

I suppose if we wanted to get really fancy we could allow this but we would need to throw an error if they use variables in the component scope (or any route export that makes it to the client).

createAction

We could do the same for actions:

// app/any/where.jsx
import { createAction, createLoader } from "@remix-run/react";

let updateProject = createAction(async ({ request, params }) => {
  let updates = await request.formData();
  return db.updateProject(params.id, updates);
});

let deleteProject = createAction(async ({ request }) => {
  let formData = await request.formData();
  return db.deleteProject(formData.get("id"));
});

let getProject = createLoader(({ params }) => {
  return db.getProject(params.projectId);
});

export function Project() {
  let project = getProject();
  return (
    <>
      <h1>{project.title}</h1>
      <Form action={updateProject}>
        <input type="text" name="title" />
        <button type="submit">Save</button>
      </Form>
      <Form action={deleteProject}>
        <button type="submit" name="id" value={project.id}>
          Delete
        </button>
      </Form>
    </>
  );
}

Similarly, this will hoist the actions to the internal route action and replace the call sites with URLs, maybe something like <form action="/this/route?__action={someId}">.

To access actionData it could work similarly to loaderData.

let actionData = deleteProject()

That looks weird though, so maybe do something like:

let actionData = useAction(deleteProject);
let actionData = deleteProject.getResult();
// can bikeshed ofc

Bundler Shenanigans

At the moment our bundler makes superficial changes to app code:

• JSX transforms from <div/> to jsx("div")
• TS transforms that just remove type annotations
• Tree shaking to remove server-only exports from client bundles

None of these transforms really change the semantics of the code.

This proposal will cross a line we haven't crossed yet. Is it worth crossing for the DX of these APIs?

[kiliman]

I see this would be useful for dashboard-type routes. I have a POC that shows component loaders, but this was done manually by importing the loaders into the main route. https://github.com/kiliman/remix-component-data

I have a couple of questions:

Will this support streaming/defer? I plan to update my POC with defer, so the dashboard renders immediately and each widget waits until the deferred data arrives.

Also, one of the issues with using route loaders for component data is that revalidation will trigger the loaders of all the components. In most instances, each widget should be able to control its data, and the initial route loader was just to "prime the pump."

Currently, shouldRevalidate is at the route level. Do you plan to expand this to also control the revalidation of component loaders?

Anyway, great proposal.

[ryanflorence]

I imagine we would find that we could get more granular with revalidation with this API, yes. If you think about a route today you've got loader and shouldRevalidate. They are coupled. I imagine createLoader could have some sort of API to have its own shouldRevalidate the very same.

[kasperpeulen]

nvm, I am writing a sibling routes proposal instead

[sergiodxa]

This reminds me a lot to Blitz, and it gives me mixed feelings.

On one side there's a clear benefit where you can build truly full-stack components with all the code related to the component in the same file without having to keep manually combining their loaders or actions.

On the other side, this will hide a lot of things, is Remix going to create a unique route per component? Where is that placed if I wanted to fetch it myself? Or is it going to merge them in the route where the component is used? If it's merged, how will that happens? What would be the response shape? What happens if the same component with a loader/action is used in more than one route?

I know that those are more implementation details and the dev using this feature will not need to care about that at all supposedly, until you need to debug something.

This hiding things feels against what Remix has done so far.

[sergiodxa]

Anyway, aside of that I think the no compiler required path is the best path for a web framework, ideally I could deploy my Remix app without running npm run build and it should work, that should be 🤩

Is there a path to have both? Features that require the compiler and if you don't use it be able to (someday) run without a build step?

[ryanflorence]

All you have access to is ({ request, params }) => {} so I don't know how you'd get the ID of the list item. You simply couldn't do it. This is why we can continue to avoid render fetch waterfalls and render fetch n+1.

This question is what I meant to address in the proposal about "limited to module scope". You can't create at render time so you don't have access to render time values:

export function Project(props) {
  // 🚫 This won't work
  let project = createLoader(() => {
    db.getProject(props.id);
  });

  return <div>{project.name}</div>;
}

[shamsup]

createLoader would get the same arguments as current loaders, you only get the request and params to decide what to load

Would this have the same params as the current leaf route? Since these components would be separate from the actual URL, it would be important to have easy access to basically useMatches, but on the server (route/loader id, params, and handle for each match for the current route). I don't think this is something we have today without digging into the internals.

[ryanflorence]

They get hoisted to the closest route loader, so not necessarily the leaf route. They are also called in parallel, so useMatches doesn't make sense there.

The middleware feature we're working on is how you will share data across loaders on the server, and it would be available here too.

All that's happening is createLoader calls are hoisted to the closest route loader by the bundler instead of you manually doing a Promise.all([bunch, of, loaders]) yourself. No change in semantics or behavior at runtime.

[shamsup]

They get hoisted to the closest route loader, so not necessarily the leaf route.

👍

They are also called in parallel, so useMatches doesn't make sense there.

I meant something like useMatches but for the server and without the data being included (data can't be included because it's loaded in parallel), just knowing everything about the route(s) this loader is being run within the context of.

[itsMapleLeaf]

Would be super stoked to see this in Remix. For every app dev that "thinks in components", being able to organize data needs and actions alongside small bits of UI without the orchestration of route-to-component prop passing, context, and/or giving up PE and using useFetcher, that's massive. Alleviates so many of my pain points.

[ryanflorence]

Yeah exactly. Imagine migrating from React Router to Remix and you've got something like React Query all over the place:

function Project() {
  let stuff = useQuery(() => fetch("/api/whatever.json"));
  // ...
}

You can make the change in placed w/o having to manually host this all to the route boundary but still remove the waterfall:

let readStuff = createLoader(() => fetch("/api/whatever.json"));

function Project() {
  let stuff = readStuff();
  // ...
}

[itsMapleLeaf]

A convention that SolidStart and Qwik have used to denote "compiler magic happening" is adding a $ to the name, like createLoader$ and createAction$. Not sure how necessary that would be here 🤔 but it's a thought

[tom-sherman]

I don't believe this is the way forward.

If Remix is going to add compiler transforms, it should be for React Server Components - these actually solve all of the stated problems here without any levels of indirection.

export function Project({ params }) {
  let project = await db.getProject(params.projectId)
  return <div>{project.name}</div>;
}

[ryanflorence]

That doesn't get hoisted to route boundaries and causes waterfalls. This API could pave the way for us to get the benefits of RSC w/o the render+fetch waterfall footgun.

[tom-sherman]

I don't think the amount of compiler magic needed here is worth it.

RSC on the other hand solve problems that aren't possible in any way with Remix right now or in this proposal and so is worth the cost.

Fetch waterfalls are potentially a problem, but I don't think it will be a big issue in practice. Loaders will still be the primary data fetching mechanis, they can even offer a nice way to share data between server components - something only possible in Next with global values right now.

[kiliman]

Also, consider that Remix plans to move beyond React, so they will need a mechanism that transcends any specific framework.

[ryanflorence]

@tom-sherman Sorry, what I mean this API could be the guard rails we need to add RSC support to Remix. I have a bag of use cases and issues with Remix that can only be solved by RSC, so I agree with you that RSC can solve things Remix doesn't. I'm eager to find a way to support RSC without repeating the decade-long mistake of component fetching replayed server side 😇

[tom-sherman]

💯 agree with this, makes total sense!

[redabacha]

i'm somewhat in favor of this proposal as it would remove pretty much all of the appeal that devs would have for data fetching in components while retaining the performance characteristics of remix. doing a bit of early bikeshedding here, i think the loader api could make more sense if it was more explicit and looked something like:

import { createLoader, useLoader } from "@remix-run/react";

let projectLoader = createLoader(({ params }) => {
  return db.getProject(params.projectId);
});

export function Project() {
  let project = useLoader(projectLoader);
  return <div>{project.name}</div>;
}

as that would avoid the need to do this Bundler replaces call sites with something like useLoader(someId) step entirely in the remix compiler i reckon. also if this were to go ahead, would it be a remix-exclusive feature (rather than also present in react router) since it relies on the compiler?

[ryanflorence]

The bundler would still need to replace the call site because useLoader(thisIsServerCode).

[redabacha]

The bundler would still need to replace the call site because useLoader(thisIsServerCode).

not necessarily. the way i see it, useLoader and createLoader could just have different implementations on the client vs the server. you'd only need to modify the callsite of createLoader to remove the server code within it for the client bundle. apart from that and some of the other aforementioned steps, a lot of the implementation of useLoader / createLoader could in theory be done via a typeof document check or similar 😅

[redabacha]

I guess that it is impossible for Remix to determine if this loader needs to be loaded or not?

yeah i think this would be impossible or very unrealistic as remix would probably need to render the route to see what loaders are going to be needed, which would defeat the whole point of this 😆

[ryanflorence]

I guess that it is impossible for Remix to determine if this loader needs to be loaded or not?

All loaders will be called when the user navigates just like today, never conditional.

[milamer]

It would be really nice to be able to bundle components and loaders on demand. This would be a great feature for a CMS that is based on blocks with each block representing a component. So depending on the CMS data different components would be bundled (and different loaders would be called)

[jrestall]

I see this as a huge win for those trying to scale Remix to large sites. Take any Amazon product page as an example. There's 20+ independent and large components on a single route: reviews, buying options, Q&A, product details, videos, comparisons, recommendations, ... . Coupling all those together in a single loader, even if just doing orchestration, would be a maintainability issue.

Those who have simple sites and requirements can keep using the one route loader I'd assume, but for those with large and complex sites with functionality and widgets developed across many teams, this would help a lot.

• This keeps components decoupled and promotes reuse.
• Components and their data dependencies can be quickly modified without modifying other parts of the system such as all the route loader's that use them. That means you won't accidentally break other components as you refactor or make changes to your app.
• Having isolated components makes it easier to have separation of concerns and team ownership of specific functionality. Allows development to scale with your teams and app complexity.
• This solves the issue of having many forms on a page that requires workarounds with useFetcher and api routes or coupling them all together on a single route. This is not good for maintainability or separation of concerns.
• Relevant to Shopify and other SaaS providers, I feel independent components would make their SaaS site extensibility easier and more granular for their customers when combined with something like Cloudflare for Platforms.

Now to really scale to the next level, there needs to be components that can be deployed independently so that the customer review team doesn't have to talk to the personal recommendations team in the other timezone/biz domain. This doesn't solve that but I think is a step in the right direction.

Localization

Also just an idea to consider and spark discussion, I thought this could be used to simplify localization without polluting every single route loader with prompts in the response or configuring clientLoader and handle for each route. Instead by simply importing the useTranslations hook it will automatically add the query seamlessly with no extra config for feature devs to worry about.

If these files could be distributed as npm packages and still have the compiler hoist createLoader, then this could simplify localization setup.

One challenge is getting the required namespace from the component in the generic loader, open to ideas!.

E.g.

// useTranslation.ts
import { useTranslation as useTranslationOrig } from 'react-i18next';

let getTranslations = createLoader(({ params }) => {
  const namespace = getNamespace(); // namespaces would likely have to be a convention based on current url?
  return loadTranslations(`./locales/${params.lng}/${namespace}.json`);
});

export function useTranslation(ns, options) {
  const lng = useLocale();
  if(!i18next.hasResourceBundle(lng, ns)) {
    let translations = getTranslations();
    i18next.addResourceBundle(lng, ns, translations);
  }

  if (i18next.resolvedLanguage !== lng) i18next.changeLanguage(lng)
  return useTranslationOrig(ns, options);
}

// app/routes/products.tsx
export default function Products() {
  let { t } = useTranslation("products");
  return <div>{t("my product")}</div>;
}

[ryanflorence]

That means you won't accidentally break other components as you refactor or make changes to your app.

This is a great point. A loader today could do all the right await and Promise.all the right way, and then somebody shows up and drops a new await that could have run in parallel and messes up the performance.

export function loader() {
  let newThing = await thing();
  // existing code did it right
  let [one, two, three] = await Promise.all([all(), the(), things()]);
  return { newThing, one, two, three }
}

[milamer]

Another great benefit of this API would be to have multiple loaders in one route

import { createLoader, useLoader } from "@remix-run/react"

let cachableDataLoader = createLoader(({ params }) => {
  const cacheableData = await db.get(params.cacheId);
  return json(cacheableData, { headers: { 'Cache-Control': 'max-age=300' } })
})

let projectLoader = createLoader(({ params }) => {
  return json(await db.getProject(params.projectId))
})

export function Project() {
  let other = useLoader(cachableDataLoader)
  let project = useLoader(projectLoader)
  return ...
}

[revskill10]

@milamer Is this the same as one loader with Promise.all ?

[milamer]

I don' think so as you can only have one cache header for the Promise.all

[airjp73]

If remix replaces getProject() with useLoader(someId), doesn't that run the risk of breaking the rules of hooks?

Something like this might look valid but actually isn't.

const Project = ({ projectId }) => {
  if (!projectId) return null;
  const project = getProject();
  // ...etc
}

If the API was useLoader(getProject) like @redabacha suggested, we could avoid that risk and rely on the rules-of-hooks lint rule entirely.

[ryanflorence]

the rules of hooks wouldn't matter since the side effects and state all live outside of the react tree, but yeah, I've imagined useLoader(fn) might be the more familiar API though technically unnecessary.

[rossipedia]

This is apparently an unpopular opinion but... I don't like this at all. It feels like it's going to lead to much messier and harder to maintain systems.

Why? Because there ain't no such thing as a free lunch.

This feels almost as wrong as monkeypatching fetch. It feels good right now, because there's some tedium and pain around declaring and defining component data dependencies.

But in my view, it's precisely those constraints that are core to why Remix is so good. Requiring your data fetching to be done at the route loader level directs you to think about your page structure in a certain way, which leads to (in. my opinion) a better, more maintainable structure / architecture.

Constraints, and limits, are a Good Thing™. Rubbing up against those constraints and feeling that friction is generally (but not always) a signal that you might be doing something you shouldn't.

I know we're all engineers, and our natural tendency is to immediately try to solve pain points, but... we've been down this path.

We've gone down the whole "let the compiler do some magical thing to make our lives easier now", and then when "later" shows up, you gotta pay the piper. And it's not fun.

Remix's strength comes from its incredibly small surface area and reliance on embracing the web, and embracing standards. Crossing this line can enable powerful patterns and features, but to use an already overused cliché: there's a responsibility there as well. It will effectively open Pandora's Box, and that's hard to close again.

I don't think y'all should take compiler magic off the table. But I think the cost of this kind of thing, in downstream effects, is incredibly high, and the reasons stated here for introducing it don't come close to justifying the possible repercussions here.

(I'm sorry if I'm coming off as a bit alarmist, it's a topic that I feel pretty strongly about).

[kasperpeulen]

@ryanflorence @sergiodxa

I guess compiling to sibling routes could look like this?

// Parent
export function Parent() {
  return <Outlet />;
}

// Leaf
export function Leaf() {
  return (
    <div>
      {/* Other code */}
      <Project />
    </div>
  );
}

// sibling
export let getProject = createLoader(({ params }) => {
  return db.getProject(params.projectId);
});

export function Project() {
  let project = getProject.useLoaderData();
  return (
    <>
      <h1>{project.title}</h1>
      <Form action={updateProject}>
        <input type="text" name="title" />
        <button type="submit">Save</button>
      </Form>
      <Form action={deleteProject}>
        <button type="submit" name="id" value={project.id}>
          Delete
        </button>
      </Form>
    </>
  );
}

// createLoader definition
export function createLoader(loader: LoaderFunction): { name: string; loader: LoaderFunction; useLoaderData } {
  const name = createUniqueSiblingName();

  return {
    name,
    loader,
    useLoaderData: () => {
      const matches = useMatches();
      const { id: currentRouteId } = matches[matches.length - 1];
      return useRouteLoaderData(`${currentRouteId}@${name}`);
    },
  };
}

let routes = createBrowserRouter([
  {
    path: "parent",
    element: <ParentModule.default />,
    children: [
      {
        path: "leaf",
        element: <LeadModule.default />,
        loader: LeafModule.loader,
        siblings: {
          [getProject.name]: {
            loader: getProject.loader,
          },
        },
      },
    ],
  },
]);

Although I'm not sure if we need this proposal, if you have sibling routes and a file system convention for it. I think having a proper sibling name, that you can see in the file system, is better than generating a random name for it. (For debugging etc.)

[jrestall]

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.

[kasperpeulen]

@jrestall I think if we adjust the sibling proposal a little bit, you could add siblings as deep as you want in the react tree, but still keep the siblings file definitions flat:

// 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
    />
  );
}

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

[ryanflorence]

@sergiodxa

createRouter([
  {
    path: "/",
    preload: [userLoader, projectsLoader],
    element: <Projects />
  }
]);

function Projects() {
  let user = useLoader(userLoader);
  let project = useLoader(projectsLoader);
  // ...
}

The compiler finds and hoists those so you don't have to do it manually.

[tshddx]

I know that codegen is a controversial subject, but I tend to be a fan of it, and with something like this I would love to be able to see some generated file that shows all the loaders that are going to be loaded on each route. This would let the team see the diffs on that generated file, which I think will be crucial for predictable performance on large projects. It will just be way too easy for some JS module to be present deep in the import graph of a large number of unexpected routes (or even just one unexpected high-traffic route), and adding a loader to that module could end up causing a lot more loading than expected.

(I've seen this happen many times over the years, e.g. with deeply nested serializers in Django REST Framework or fragments in GraphQL.)

[duailibe]

My problem with this suggestion is mostly that this separation of loaders looks more useful than it will be in practice. Sometimes the data you load are dependent of other data:

const getCart = createLoader(({ request }) => fetchCart(request));
const getRecommendedProducts = createLoader(({ request }) => {
  const cart = await fetchCart(request);
  return fetchRecommendedProducts(cart.lines);
});

Now, you have to make sure you deduplicate the fetchCart call in the same request, and it might be easy to do so in this simple example, but think about simply importing a component and then you have to make sure the fetch isn't duplicated.

This kind of optimization "left to the user" kind of reminds me how the user can make sure to not have waterfalls in RSC.

[itsMapleLeaf]

Doesn't this also apply with the current loader API?

[duailibe]

@itsMapleLeaf a bit yes, but this problem was constrained only to routes in the same route hierarchy. This proposal is introducing a way for any module in your module graph to fetch data, so now you need to inspect your whole module graph for this kind of problem.

[yesmeck]

Instead of code transforming, how about putting loader and action in a separate file alongside the component file?

// /app/components/List/index.action.tsx <= the action suffix indicates this is a action file of the component
import { createAction, createLoader } from "@remix-run/react";

export let updateProject = createAction(async ({ request, params }) => {
  let updates = await request.formData();
  return db.updateProject(params.id, updates);
});

export let deleteProject = createAction(async ({ request }) => {
  let formData = await request.formData();
  return db.deleteProject(formData.get("id"));
});

export let getProject = createLoader(({ params }) => {
  return db.getProject(params.projectId);
});

// /app/components/List/index.tsx
import { getProject, updateProject, deleteProject } from './index.action';

export function Project() {
  let project = useLoaderData<typeof getProject>();
  return (
    <>
      <h1>{project.title}</h1>
      <Form action={updateProject.endpoint}> <= action exposes a endpoint property points to the action route
        <input type="text" name="title" />
        <button type="submit">Save</button>
      </Form>
      <Form action={deleteProject.endpoint}>
        <button type="submit" name="id" value={project.id}>
          Delete
        </button>
      </Form>
    </>
  );
}

[itsMapleLeaf]

honestly? I could live with actions in a separate file, but having one file per action would be kind of awful

[yesmeck]

Sorry, I didn't describe it very clear. Defiantly, we can put multiple actions in the separate file. I've update the example.

[shamsup]

I love this proposal as it's just the compiler moving some code around, not changing any Remix fundamentals, and most likely reducing confusion around what is and isn't allowed to have loaders/actions. I did notice something missing, though: component-level ErrorBoundary (and CatchBoundary).

It seems like it would add confusion to only be able to have route-level error boundaries, but define loaders and actions that could error anywhere. The loader for a <Reviews /> component in an e-commerce site throwing an error shouldn't crash the whole page, right?

[pcattori]

This proposal combines loader definition via createLoader with automatic detection of loader usage via compiler.

I want to call out that these two concerns are orthogonal. For example, we could have a createLoader$¹ that tells the compiler "hey, there's server stuff in here. please don't include it in the browser bundle":

import { json, createLoader$} from "@remix-run/..."

// can define `peopleLoader` here or import from another file, doesn't matter
let peopleLoader = createLoader$(() => {
  let raw = fs.readFileSync("people.json", "utf8")
  let people = JSON.parse(raw)
  return json({ people })
})
// ^ typechecks like `satisfies LoaderFunction` but without having to write that manually!

// explicitly declare what loaders this route uses (parent loaders still get run automatically, this is just for new loaders for this route)
export let loaders = [peopleLoader]

export default Route() {
  let { people } = peopleLoader.useData() // look ma, no `typeof loader`!
  return <pre>{JSON.stringify(people)}</pre>
}

Using something like a loaders export keeps things explicit and does less magic. The only compiler magic this is doing is another form of "remove server stuff from the client" that we already do.

// for browser build, compiler replaces `createLoader$` with something like:
let peopleLoader = { useData: () => useLoaderData(peopleLoaderId) }

So if you don't like the compiler auto-detecting the loader usages in your code (which I agree is a bit more magic), you might still like the explicitness and DX of createLoader with no auto-detection but instead explicit loaders export.

Footnotes

1. Using the $ convention established by other frameworks to indicate that "compiler stuff is going on here". Again, API tbd ↩

[brophdawg11]

Agreed this is tricky at scale. We've seen some POC-ideas before for auto-detecting unused loaderData on render that could maybe be useful here .

I also think there's an inverse problem introduced by createLoader which is that folks stop thinking in Routes and start thinking only in Components - resulting in over-fetching at the Route level.

• Developer 1 adds <ProductImages> which has a createLoader to hit the /api/product endpoint for image data.
• Developer 2 comes along sometime later and adds <ProductSkuSelector> with it's own createLoader that hits the /api/skus endpoint ... but shoot it also needs a tiny bit of metadata from /api/product so that gets dropped into it's createLoader as well.

Now our server-side fetches consist of:

GET /api/products
GET /api/skus
GET /api/products

I know this is a bit of a contrived example since both of these are front and center for a PDP route, but the lack of clarity about what data is already available at a given route feels like a potential performance footgun. Especially given the lack of clear visibility into the server side fetches - it's not like you'd see /api/products twice in the DevTools Network tab (still hoping Node can add this via the profiler or inspector someday 🤞).

Maybe the guidance in a scenario like this is to export your createLoader from a shared location to be imported by both components? Presumably we could detect that the components used the same underlying createLoader and de-dup at the route level?

[pcattori]

Level 0: What we do today

export let loader = () => json({ hello: "world" })

export default function Route() {
  let { hello } = useLoaderData<typeof loader>()
  return <h1>{hello}</h1>
}

Level 1: createLoader$

export let loader = createLoader$(() => json({ hello: "world" }))

export default function Route() {
  let { hello } = loader.useData()
  return <h1>{hello}</h1>
}

DX improvements:

• Typesafety without room for user error
  • No need for LoaderArgs or satisfies LoaderFunction when authoring loaders
  • No need for typeof loader when consuming loader data
• Loaders can be defined anywhere, but must be wired up to a route just like in Level 0

Changes:

• Instead of removing entire loader export, compiler replaces loader with { useData: () => useLoaderData(loaderId) } in browser bundle. Compiler uses AST tranforms to do this rather than relying on virtual modules.

Level 2: Multiple loaders per route

import { loader as blahLoader } from "~/lib/blah"

export let loaders = {
  hello: createLoader$(() => json({ hello: "world" })),
  sup: createLoader$(() => json({ sup: "planet" })),
  blah: blahLoader,
}

export default function Route() {
  let { hello } = loaders.hello.useData()
  let { sup } = loaders.sup.useData()
  let { blah } = loaders.blah.useData()
  return (
    <main>
      <h1>{hello}</h1>
      <h2>{sup}</h2>
      <h3>{blah}</h3>
    </main>
  )
}

DX improvements:

• Easily compose multiple loaders defined across app into one route

Changes:

• Assets manifest needs to support multiple loaders per route and navigation has to revalidate multiple loaders

Level 3: Auto-detection of loaders

import { loader as blahLoader } from "~/lib/blah"

let helloLoader = createLoader$(() => json({ hello: "world" }))
let supLoader = createLoader$(() => json({ sup: "planet" }))

export default function Route() {
  let { hello } = helloLoader.useData()
  let { sup } = supLoader.useData()
  let { blah } = blahLoader.useData()
  return (
    <main>
      <h1>{hello}</h1>
      <h2>{sup}</h2>
      <h3>{blah}</h3>
    </main>
  )
}

DX improvements:

• No need for manual wiring up of loaders to routes
• Impossible to have unused loaders wired up to a route

Changes:

• Compiler auto-detects loaders for each route by crawling dependencies / manual treeshaking

---

Note: its possible to do Level 2 without Level 1. I just ordered them this way as it was the most logical progression from what we have today to what is in the original proposal.

I'd argue that the jump from Level 0 to Level 1 is small and has no negative trade-offs, or at least the positive trade-offs vastly out weight any negatives.

The jump to Level 3 I think brings great DX improvements, but has non-negligible negative trade-offs. Is it still worth it? I'd say probably yes, but its not a no-brainer. Whereas I think going from Level 0 to Level 1 is a no-brainer.

[brophdawg11]

💯 this is almost exactly how I posed this in a Discord thread the other day. This proposal feels like it might benefit from being split into incremental sub-proposals to be evaluated independently:

[sergiodxa]

+1 to @brophdawg11, I think 1, 2 and 3 are great, but I'm not convinced about 4.

[kasperpeulen]

@brophdawg11 @pcattori But can I use createLoader$ then also in react router? I think it would be best if it is actually come from RR. Maybe something like:

// createLoader$ definition in RR
export function createLoader$(loader) {
  const id = createRouteId();

  return {
    id,
    loader,
    useData: () => {
      return useRouteLoaderData(id);
    },
  };
}

So that it is still possible to do style 1) and 2) in RR by importing the loader and add it to your route definition:

import * as FooModule from "~/routes/foo.tsx"; // 1
import * as BarModule from "~/routes/bar.tsx" // 2

const router = createBrowserRouter([
  {
    path: "foo",
    id: FooModule.loader.id,
    element: <FooModule.default />,
    loader: FooModule.loader.loader,
  },
  {
    path: "bar",
    element: <BarModule.default />,
    loaders: BarModule.loaders,
  },
]);

This would also make sure that Remix keeps being easily testable by mocking it with RR.

[maranomynet]

@ryanflorence I keep thinking: Could this sort of thing be designed as a form of progressive enhancement?
…Where the code-gen compilation step is an optional optimization, but some less performant/elegant solution is the default/fallback behavior?

The uncompiled vanilla JavaScript version might involve double-/pre-rendering to figure out which loaders are being defined for a given route (at least on first render), somthing, something...
(I obviously haven't thought this completely through.)

[itsMapleLeaf]

Is there still interest in this? What's the team's current thoughts on this?

[danramos-evoiq]

@ryanflorence really looking forward to seeing this, any update? Or any workarounds you'd recommend in the mean time?

[milamer]

Hello everyone,

I've been mulling over the topic as well as the inputs shared by @rossipedia . I reckon another approach could be to maintain the route loader while also feeding it all defined loaders from its module graph. This would be encapsulated in an object, offering dynamic call functionality along with the ability to include custom parameters, contexts, and more.

Here's the API I've been considering:

// blogPostList.tsx
// blogLoader is a Symbol
export const blogLoader = createLoader(function loader({params}){
  const posts = loadBlogs(params.page)
  return json(posts)
})

export function BlogList() {
  const posts = useLoader(blogLoader)
  ...
}

// $pageSlug.tsx
import { blogLoader } from '~/blogPostList'

export function loader({ params, childLoaders }) {
  const pageData = await loadPage(params.pageSlug)
  for ([loaderKey, childLoader] of Object.entries(childLoaders)) {
  if (loaderKey === blogLoader && pageData.some(data => data.type === 'blog-list')) {
    childLoader({ params: { page: 0 }})
  } else if (loaderKey !== blogLoader) {
    childLoader()
  }
  return json(pageData)
}

In this scenario, 'childLoaders' acts as a dictionary where the loader key maps to a function that triggers the corresponding loader. The parameters of these loaders can be overridden, and the loaders themselves can be called concurrently.

If you'd like to call all child loaders without overriding any parameters, it's as simple as iterating over them like so:

function loader({childLoaders}) {
  Object.values(childLoaders).map(childLoader => childLoader())
}

Or childLoaders could already be a list of entries. What I am in general not sure about is: what if two components are rendered twice and would need different data.

Would love to hear your thoughts on this approach.

[684efs3]

Any updates on this?

[sergiodxa]

Remix will adopt RSC and Server Actions eventually, which will defeat the purpose of this RFC, so I doubt it will happen

[h3har]

Is there a link to any discussions where I can learn more about this?

[iwan-uschka]

Probably #8048

[Annukul]

If you load data inside of components you slow down your app so we made that hard.
Can anyone elaborate on this statement by @ryanflorence ? Or have any resources which I can refer to - I am really curious and want to read more on this.

[sergiodxa]

Let's say you have a component A, B and C, they're rendered like this:

<A>
  <B />
  <C />
</A>

If A needs to block rendering (either with suspend or by doing if (status === "loading") return <Spinner />) then the data fetching of B and C won't start until A finish loading.

If B and C depended on the data of A it wouldn't be a problem because you can't start fetching B and C data until you have A data, but if they don't depend on that, then you'r blocking fetching B and C for nothing.

In a loader this doesn't happen because you can trigger all A, B and C fetches in parallel, to solve this with components you would have to prefetch B and C before rendering.

let a = fetchA()
let b = fetchB()
let c= fetchC()
return (
  <A data={a}>
    <B data={b} />
    <C data={c} />
  </A>
)

Note those fetchA, etc. don't await the data, so it's only triggering the fetch, you can await it inside the components, this way you're unblocking B and C to start loading the data they need, which means your UI will be as slow as the slowest fetch call, instead of the sum of A + B or C.

This is the reason why fetching in components makes your app slower, you can solve it, yes and Remix loaders is one way to do it,