🗺️ RFC: React Elements and Promises as loader / action data

[jacob-ebey]

Summary

This proposal seeks to introduce the ability to return Elements and Promises from loaders and actions in Remix. This will allow developers to return fully rendered components from loaders and actions, enabling a more flexible and robust approach to web application development that closely aligns with the HAETEOAS (Hypermedia as the Engine of Application State) paradigm.

Example

// loader
function loader() {
  const { title, content } = await loadArticle();

  return {
    articleHeader: <Header title={title} />,
    articleContent: <AsyncRenderMarkdownToJSX makdown={content} />,
  };
}

export default function Component() {
  const { articleHeader, articleContent } = useLoaderData();

  return (
    <main>
      {articleHeader}

      <React.Suspense fallback={<LoadingArticleFallback />}>
        {articleContent}
      </React.Suspense>
    </main>
  );
}

Motivations

"New" programming paradigms

Remix currently adopts a model-view-controller (MVC) like structure:

• Model: Up to you and your use-case, usually a layer you reference in your loaders / actions.
• View: Represented by route default export components.
• Controller: Encompassed within loaders and actions.

This structure, while familiar and effective, creates a tight coupling between data retrieval (loaders) and display (view layer), resulting in a potential expected vs retrieved data mismatch between your deployed loaders and the view layer running in your users browser.

Failure Example

function loader() {
  const { title, content } = await loadArticle();

  return {
    article: {
      title,
      content,
    },
  };
}

function Component() {
  const { article } = useLoaderData();

  return (
    <main>
      <Header title={article.title} />
      <Article content={article.content} />
    </main>
  );
}

Let's imagine we have a user browsing the above application and we deploy a new version that makes the following code change innocently re-naming a property on the article from "content" to "html".

function loader() {
  const { title, html } = await loadArticle();

  return {
    article: {
      title,
      html,
    },
  };
}

Our user is still browsing the side and their route component doesn't know about the new shape of the article data, that means our route component will be rendering this:

function Component() {
  const { article } = {
    article: {
      title: "some title",
      html: "some html",
    },
  };

  return (
    <main>
      <Header title={article.title} />
      {/* content isn't a property of article anymore */}
      <Article content={article.content} />
    </main>
  );
}

Ultimately we didn't make any changes to what or where data is surfacing, just how the server hands off the data to the view layer.

How to avoid this

Let's change up the paradigm a bit and instead of returning data to our View layer, let's return pieces of view to our View layer. We'll return what and how to render, not just what. This decouples deep data access in the View layer (that can lag behind in deployments and has the same issues that the /api/v1, /api/v2 versioning is meant to solve), and instead only couples where to surface things.

Let's look at how we can structure the above in this "new" paradigm:

function loader() {
  const { title, content } = await loadArticle();

  return {
    articleHeader: <Header title={title} />,
    articleContent: <Article content={content} />,
  };
}

function Component() {
  const { articleHeader, articleContent } = useLoaderData();

  return (
    <main>
      {articleHeader}
      {articleContent}
    </main>
  );
}

This may not feel like we are doing much here other than moving the Header and Article components up to the loader, but we have moved the how to display responsibilities of header and article up to the loader (server) and they have become part of our application state, instead of their data and what to display. What does that mean for the example that broke an active user earlier? Well, we can now make the change, the browser loads the payload with the same properties, and is surfacing the new way of showing in the same location.

function loader() {
  const { title, html } = await loadArticle();

  return {
    articleHeader: <Header title={title} />,
    articleContent: <Article content={html} />,
  };
}

function Component() {
  const { articleHeader, articleContent } = useLoaderData();

  return (
    <main>
      {articleHeader}
      {articleContent}
    </main>
  );
}

Streaming Data (and Components)

Streaming promises is currently only enabled through the use of the defer() utility, and is restircted to only root level promises for data. Leaning into React 18 and the rules around suspense, we can enable streaming of arbitrary promises, including promises that return React elements or event more promises, all through native React features, including the transport format.

RSC (React Server Components)

This proposal is enables a HATEOAS-inspired approach to building React applications using Remix, it just so happens that RSC is the technology that enables this. RSC is a technology that allows you to render React components on the server and stream them to clients, hydrating only the interactive bits. This is a huge win for performance and developer experience.

Backwards Compatibility

This proposal is completely backwards compatible with existing Remix applications. The only change is that you can now return React elements and promises from your loaders and actions, instead of just JSON encoded or defer encoded data. This is accomplished by enabling the naked object returns, as well as a new response helper (maybe rsc(<div/>, { headers: {} }) or something similar) to opt into the new behavior and encoding format for your data.

Multi Deployment

A future split at the component / loader / action level in this world also means it would be super easy to split your application into multiple deployments, allowing you to deploy your loaders and actions to a different domain, or even a different hosting provider, than your view layer. This would allow you to scale your application in a way that makes sense for your use-case, and not be tied to a single deployment strategy.

Challenges

• Need to take ownership of, and implement the RSC plugin for Vite (in the react repo? as a fork so we can move quick and publish along the way?)

Conclusion

This proposal seeks to introduce the ability to return Elements and Promises from loaders and actions in Remix. This will allow developers to return fully rendered components from loaders and actions, enabling a more flexible and robust approach to web application development that closely aligns with the HAETEOAS (Hypermedia as the Engine of Application State) paradigm.

It also just so happens that this proposal is the first step in enabling React Server Components in Remix in a way that is backwards compatible with existing applications, and allows for a smooth transition to a more robust and performant approach to building React applications.

[jacob-ebey]

A super hacky, "works on my machine", proof-of-concept was done to see what it might feel like: https://github.com/jacob-ebey/remix-rsc-webpack/tree/main/fixtures/basic/app/routes/about

[oncet]

Loved the idea! But not sure about the example, wouldn't the proposal still carry the same problem? The loader may be modified to return articleBody instead of articleContent and break the rendering of Component.

[oncet]

I agree with AdiRishi, I feel like exporting an almost empty component doing a single call to a hook is weird. Could it be possible to just export a loader for that case?

[jacob-ebey]

"Just a loader" is a resource route so we need some indication. I'm thinking that single line component would be an export from the remix lib. export default RSCRoute where RSCRoute is imported from remix and just re-exported.

[sergiodxa]

@jacob-ebey it could easily be added to Remix Utils too so people play with that and later add it to Remix itself if needed, or maybe never if in a future major you do a switch to consider route components to be server components

[jacob-ebey]

I'm thinking it should come from remix because theres a potential compiler / chunking optimization we could make to allow N client routes to share a single bundle entry point and avoid a JS chunk per route.

[AdiRishi]

Okay, I spent the time to watch the roadmap planning where this proposal was discussed. I think I understand the proposal much better now, my concerns are mostly not founded. Really great stuff, looking forward to this :)

[jacob-ebey]

IDK how to fit this into the proposal because I want it to focus more on what it enables, and not how, but I've been thinking about the default route component export as your "entry into the RSC router". RSC router implementations so far essentially deconstruct or re-assemble a tree structure from the RSC payload. In contrast, here each route is an RSC payload you control the shape of and compose however you see fit at a route level. "Per route RSC router".

[gustavoguichard]

I love the new capabilities! My doubts are about the boundaries and hierarchy between RSC and Regular components.
In this approach, how do you render client components as children of the RSC and vice-versa?

[jacob-ebey]

You can't pass props client -> server except through actions, that's just how RSC is designed. You can however compose client components inside your server tree, and compose parts of a server tree as children or props to client components.

"use client" / import and render in a loader / action to add regular components to the server tree and hydrate them in the browser.

Pass rendered elements from "useLoaderData()" to your existing client react app to compose bits of server in the client.

[afoures]

one thing that we do sometimes in the loader is to cache the data that we load, would it be possible to cache a component rendered in a loader, like in a lru or redis ?

[jacob-ebey]

Yes

[sergiodxa]

If you get the data in the loader, outside the SC, it should also be possible to cache the data directly, if not you can also use a cache or fetch approach inside the components.

[sergiodxa]

I like this approach, the migration story will be super simple, let me gradually move parts of my UI to the loader when it makes sense, instead of having to do a big bang migration to SC or mark everything a client components (having to forcefully move components to another file just add "use client").

The fact that I have a loader that receives a request and sends a response means I could also keep checking auth and doing a lot of other things in the loader before starting to render the SC, for redirects in particular this will be way better than having to do a tacky approach to do a redirect since the loader runs before I start streaming the HTTP response.

I can also optimize how I get the data in the loader and then pass the results to the SC to render, or I can let SC do the data retrieval, or a mix of both where most important data is optimally loaded first and leaf data is loaded in the SC.

And with useFetcher integration I will be able to do nice things like render a notification bell button that when clicked it fetches the notifications to render inside a dialog, but instead of sending the data I can just send the JSX directly and later do <Dialog>{fetcher.data}</Dialog>.

It will also let me avoid sending possible sensitive data only to be used as a React key.

[JClackett]

a little concern I have is that if they dont release the export function Component() straight away i.e. the RSC version of the route component, people will be tempted to move everything up to the loader only to then move it back as soon as the RSC is available. Sometimes, as shown in the roadmap planning, you do just wana use some state in the top level component and so the loader RSC's are great. But I definitely have a few routes I know I wana go full RSC, and I either have to do 2 refactors, or wait.

[sergiodxa]

Multi Deployment

A future split at the component / loader / action level in this world also means it would be super easy to split your application into multiple deployments, allowing you to deploy your loaders and actions to a different domain, or even a different hosting provider, than your view layer. This would allow you to scale your application in a way that makes sense for your use-case, and not be tied to a single deployment strategy.

This is really interesting, it should be possible to deploy the server-side rendering part of the app (the one that outputs HTML) to the edge using Cloudflare Workers so that happens near users, but keep loaders and actions in a single location where I have more direct access to the DB or I'm near my API.

[sergiodxa]

I wonder if it would be possible to get a stream response from another route and return it from the loader.

export async function loader() {
  let response = await fetch("a url that returns JSX from another Remix app")
  return rsc({ 3p: response.arrayBuffer() })
}

This way, I could grab the JSX from another route and compose it inside my own app.

[jacob-ebey]

That will require something like federation to "merge" multiple runtime graphs so things like React resolve to a singleton, and a client that doesn't know about a client component in another app has a bridge to load it. This is something I'm interested in but not a goal of this proposal.

[Fawwaz-2009]

Hey everyone 👋 , I've only been using remix for a short time and I'm excited for this RFC and the introduction of RCS.

I have a question about the multi deployment point. I always thought that we deploy a remix App as single deployment. But if I understand this new paradigm correctly, we could have multiple remix apps with different responsibilities (eg billing) and the "view-layer" remix app.

my question is how would the "view-layer" remix app use RSCs from say the billing Remix app?

[sergiodxa]

From what I understood is that that your app breaks between the view-layer and other parts of the app (e.g. billing, auth, etc.), but you have two parts.

The loaders and actions part (let's call it data-layer) where you get the data and return data, JSX, or both.

And the server-rendering part (the view-layer), which takes that data and JSX and renders HTML out of it.

You can still deploy them as a single app but it may be possible to deploy them independently to different targets, in a comment I left I mentioned using an edge platform like Cloudflare Workers for the view-layer part and a single origin server (e.g. AWS or Fly.io) for the data-layer.

[Fawwaz-2009]

hey @sergiodxa I think conceptually I understanding what you are saying, but let's take an example. First I'm going off on the assumptions that anything including loaders, actions and the view-layer must be encapsulated in a Remix app.

Going off that say we have a remix app that has our loaders that will serve JSX for Billing, and it is deployed in Cloudflare workers. We also have our "view-layer" Remix app deployed to AWS.

What I'm having trouble understanding is, how would the "View-layer" remix app use the loaders from the Billing remix app, to compose JSX and render a page?

[jacob-ebey]

Today:
SSR Bundle

• contains loaders, actions, and everything the browser build does

Browser Bundle

• contains everything except loaders and actions

Tomorrow:
Server Bundle (s)

• contain loaders and actions per route
• potentially 1 server bundle per route
• potentially N server bundles per "verticals"

SSR Bundle

• contains "use client" references and contains everything except loaders and actions
• instead of calling loaders and actions, has a "configurable" bridge to invoke loaders / actions
  • Could be "import and call server bundled loaders / actions"
  • Could be "deploy server bundle and call via HTTP request"

[lubieowoce]

Do you have any ideas of how "use server" plays into this? it covers similar ground to remix's own Actions, which sounds like it could get messy.

[jacob-ebey]

Nope, not yet. That's for sure a separate proposal

[JClackett]

With this RFC, is it not possible to pass "client" components as children to server components? Sometimes you have a very static server component that just needs a little client component inside it.

[JClackett]

Or is it that it has to be nested inside the component returned from the loader? using a "use client" directive

[JClackett]

Also just seen that you are planning on supporting export async function Component, which would also solve it

[JClackett]

It feels like the export default name for the component could be a named export instead and called "ClientRoute/Client/ClientComponent" or something, as by that point you're on the client right? and makes it clearer that any code related to the jsx thats returned (excluding the server components) is sent to the client.

[JClackett]

Yeah and maybe as you're gonna support the export async function Component, having an export async function ClientComponent makes it clearer what you're writing

[jacob-ebey]

The point is partly existing remix "client react" continues to work through the existing default export and migration is incremental and ends in a new route level API for the new behavior. (export).

[JClackett]

Yeah just need to remember which one is RSC, which one is client react :)

[swalker326]

Whats the point of having the loader return the async data, couldn't you move the content of the loader down into the Component and just make the component async? I like the stark contrast of "this has has a loader, its a client component".

[gustavopch]

They talked about your specific point in today's roadmap planning: https://www.youtube.com/watch?v=VQAYY5k44vA

[lili21]

what is AsyncRenderMarkdownToJSX? do we support async component? what is async component in Remix?

[sergiodxa]

It's an example, like the Header above that.

This proposal to let loaders and actions return server components will also enable async components to work since those are server components.

[lili21]

I like the ideal, but I'm not sure about the example, the motivation and the HAETEOAS stuff.

the RSC part is what I really want. maybe we can give more detail about that.

[arnaudbzn]

Naming:
useLoader() instead of useLoaderData() will definitely improve readability using a mix of RSC and "data". No breaking change is required, just introduce this new hook with the same behavior as useLoaderData().
Same for useActionData() => useAction().

[JClackett]

Me likey

[akomm]

I like that the primitives loader and action remain. I like the addition approach. Sounds to me like there will be no need for "use client", since the RSC is just an addition to render components on the server, not interleave like in nextjs. In nextjs you could technically write server code, get headers and such in every RSC component and nest and interleave with client components, while in remix you would have to enable each such component to have own loader outside of routing, which doesn't feel right. TBH I kind of like this Idea of keep it loader and action and add the ability to return components vs. the interleaving in next. In next you are also forced to create artificially extra files just for the "use client". IN remix having them only come from loader and/or action would eliminate the need. At least if the RSC rendering the same way as the default exported route component (tree), which means you can naturally then use client hooks in the RSC or its children, without the need of separation.

[sergiodxa]

there will be no need for "use client"

You will still need it for any client component rendered on the loader, although if you follow a PE enhancement approach most of your client components will be Link and Form from Remix.

[akomm]

Thanks for clarifying. I was just thinking since the component part (not loader) currently does not need it (runs on both sides, but differently) you might not need it on server. But I guess its about what you send to browser to hydrate (use client) and what not (RSC)?

[sergiodxa]

The route component (the one you export default) will not need "use client", it's going to be a client component by default.

This also means that any component imported and rendered directly there will also be a client component so you could consider most components to be client components.

The components you render in loaders are server component, so you may also don't need "use server" for them, but if your server component renders a component with hooks you will need to mark it as a client component, so it hydrates.

[jamesholbert]

So I have a Full Stack Component (Kent's pattern) that reads skill codes from the url on initial load in order to show data like "skill names". Currently I'm doing the lookup with a useEffect and "lookup" fetcher (syncing the component with the url).

With RSC will I be able to do this?

// pretend this actually does a lookup
export const getMetaData = async (codes: string[]) => [
  { name: "Coding", code: "aaaa" },
  { name: "Planning", code: "bbbb" },
];

// what I call in the primary/route loader
const FilterRSC = async ({ codes, type }) => {
  const metaData = await getMetaData(codes);

  return <Filter type={type} {...metaData} />;
};

// this would hit a resource route loader for skill searching using a fetcher
const Filter = (props) => {
  "use client";

  return <FetcherSelect {...props} />;
};

export async function loader({ request }) {
  const codes = await getCodesFromSearch(request.url);

  return {
    filters: {
      skills: <FilterRSC type="skills" codes={codes} />,
      jobs: <FilterRSC type="jobs" codes={codes} />,
    },
  };
}

and is the primary use case for why this is better is because it helps keep a ton of extra logic out of the loader?

I'm trying to properly understand the value since I could technically do all those lookups in the loader and just pass everything to my components as props.

[lubieowoce]

RE this bit:

const Filter = (props) => {
  "use client";
  return <FetcherSelect {...props} />;
};

inline "use client" is not part of the RSC spec, it needs to be in a separate file. and afaik the React team has been opposed to mixing "server" and "client" code in the same file. so if remix decides to add that, it'd be a framework-specific extension, i don't know if they wanna go that way

[bondepike]

Would be cool if I could throw a JSX component in the loader which aborts any further work and renders this component.
Similar to how I can throw a redirect(_:)

[akomm]

Imagine throwing a component into an error boundary.

[sergiodxa]

You can throw responses, maybe you could throw a response with a component and grab it in the error boundary.

[akomm]

Yes I know you can throw responses :). That is what I meant implicitly.

[lili21]

what's about streaming?

// loader
function loader() {
  const { title, content } = await loadArticle();

  return {
    articleHeader: <Header title={title} />,
    articleContent: <AsyncRenderMarkdownToJSX makdown={content} />,
  };
}

do we need to await the async component? how to stream the component?

[sergiodxa]

This is in the RFC:

Streaming Data (and Components)
Streaming promises is currently only enabled through the use of the defer() utility, and is restricted to only root level promises for data. Leaning into React 18 and the rules around suspense, we can enable streaming of arbitrary promises, including promises that return React elements or event more promises, all through native React features, including the transport format.

[lili21]

if my understanding is right, async component is restricted to loader aka route level. so we still need the defer utility for component streaming, right?

[sergiodxa]

async component is restricted to loader aka route level
Yes, async components and any server component will only work on loaders (server-side).

so we still need the defer utility for component streaming, right?

From Jacob comments on Twitter, Discord and here, there will probably be a rsc response helper to return components, it will probably work similar to defer.

[lili21]

is it a good idea return component from loader/action?

is it possible that we can just use server component like Next?

[lili21]

1. we can only define loader/action at route level,
2. as project be more complicate, the loader get more and more code/logic, if we put server component inside loader, the loader would be hard to maintain eventually.
3. the server component will be hard to reuse, and be less composable.

[Fireclunge]

From what I can gather it would be completely optional and only gives more power to the developer

Here's my usecase:

If (user.isLoggedIn) {
  return <Dashboard/>
} else {
  return <LandingPage/>
}

This would help with SSR code splitting based on conditions so it's something I personally would be very much interested in having

[brunocascio]

What about using something similar to Next?

export default async function Component() {
  // blocks render until getArticle is resolved
  const { article } = useLoaderData(await getArticle());
  // stream article when it's resolved
  const { article } = useLoaderData(getArticle());

  return (
    <main>
      ...
    </main>
  );
}

IMHO, in the react world (at least), by having everything close to the component makes it better readable

[jamalsoueidan]

Any update regarding this?

[alexanderson1993]

Currently marked as in-progress on the roadmap: https://github.com/orgs/remix-run/projects/5

Also, I'm pretty sure Single Fetch is a dependency of this feature, so you won't see it at all before Remix 2.9 is shipped.

[jamalsoueidan]

So we can guess it will be around end of the year.

[alexanderson1993]

I'm not going to make any predictions, just things that I know based on conversations from the core team.

So it's happening some time between Single Fetch, since that's a dependency, and Remix v3, since they've said this will be one of the future flags included in Remix v3.

But I don't think its wise to put a deadline or expectation on it, since that might put undue pressure on the core team when they should be focusing on building.

[jamalsoueidan]

No worries, thank you :)

[carlokok]

Will rsc be CDN cachable? For example for during page navigation? Afaik it's not on nextjs, but if setup properly it should be possible to return it with a cache header?

[zerosym]

There is a lot of prior art related to this, just in the other direction from traditional server oriented frameworks trying to adapt and add more interactivity. It's pretty nifty to see both sides (MPA and SPA) finally meeting in the middle after all these years.

A bit of context or side reading for anyone who might be interested:

Phoenix LiveView (original release in 2018, 1.0 release is recent)
https://phoenixframework.org/blog/phoenix-liveview-1.0-released

Phoenix was one of the pioneers of this approach. The link is a post by the author of LiveView (and Phoenix, and Elixir) who even makes mention of React Server Components and the parallels.

Htmx
https://htmx.org/essays/hateoas/

A primer on HATEOAS. HTMX itself is a library that implements this sort of behavior à la carte.

Couple of other notable LiveView style frameworks you may have heard of, tossed in for good measure.

Rails Hotwire
https://hotwired.dev/

Laravel Livewire
https://laravel-livewire.com/