Feature: enable data components to have their own loader and actions

[fergusmeiklejohn]

I have lots of what I might call data-routes. They aren't actual routes with a URL, but they are discrete data components which require and mutate data, then pass it down to dumb components in the tree.

I think it would be useful for each data-route to have it's own loader and action.

Imagine a blogging app as an example: The main data in route /blogs/$blogid would be the blog post, if that errors loading data you want to throw a 404, but the blog post route has other components like comments, polls, a game users play, user uploads, authentication.. None of them are routes but each of them could error (maybe they all call 3rd party APIs) and you'd not want to throw a 404, you'd want to the component to show some sort of error state alongside the other properly functioning components in the route. It's the same with data mutations, the comments component will handle comments mutations, the polls component polls mutations etc. This would be easier to do if each was a what we might call a "data-route" with it's own loader and action functions.
This would also make these components easier to reuse.

Various proposed solutions in Discord:

Ryan Florence

import User, { loader as user } from "~/components/avatar";
import Project, { loader as project } from "~/components/project";
export function loader(arg) {
  return Promise.all([
    user(arg),
    project(arg)
  ])
}

sergiodxa

"create function per component that receives any required param and do the data fetching, that function shouldn’t throw an error, instead it should return an object saying if it was a success or failure and the data or error, then in the route loader you call those functions and return the result as is, you don’t do anything to handle the errors, in your route component you call useLoaderData and pass each key which, should have the data of a single component, to each component so they can check if it was an error or not show a different UI"

Kent C Dodds
"create a hidden input on the form to identify it in the parent route action":

<input
  type="hidden"
  name="actionType"
  value={actionTypes.DELETE_RECORDING}
/>

[chaance]

I believe we should have marked this resolved when we introduced resource routes! 🎉 Let me know if I misread the issue, but I think that's exactly what you were looking for here.

[fergusmeiklejohn]

Resource routes sort of solve it in another way, and perhaps make the suggestion less valuable.
I still think that a way to bring data loading and mutation down to the component level would be useful.
I'd like to be able to fetch only the data that has changed not the whole route, and I'd like to be able to co-locate component code with loader and action for that component.

[chaance]

I still think that a way to bring data loading and mutation down to the component level would be useful.

This has come up a few times with various ideas. I'll move this over to discussions so we can try to consolidate until we come up with a solution here.

[kiliman]

I have the component data POC I created. You still have to use the route loader/action as the entry point for the component though. But it does support component level Error/Catch boundaries.

I think the new deferred loaders that's coming soon would make this even more interesting.

https://github.com/kiliman/remix-component-data

[terranboy]

I think loader/action with component will be great. Because many websites have many components in one route but have not many nested routes.

[luispuig]

I am also working on this. Would please check this experiment? I also opened a RFC in remix-utils sergiodxa/remix-utils#88 https://github.com/luispuig/remix-tracks

[lucgagan]

What's the latest here?

[684efs3]

Any updates?

[SteveSuv]

another discuss: #5383
now you can use this: full-stack-components
and finally remix will use RSC

[willhoney7]

thank you for sharing the information about full-stack-components. I think this needs to be highlighted in the docs! Big gamechanger for us as we've been debating between next and remix.