🗺️ Single Data Fetch

[ryanflorence]

Single Fetch for Data

This proposal aims to simplify the data fetching story in Remix by making document and data requests consistent by making a single fetch for data instead of one per route.

While this has current benefits (like better CDN caching for pages) it also prepares apps for future features:

Benefits today

• Better CDN cache coverage
• Simpler headers (cookies, sessions, etc.)
• Simpler code paths in Remix itself

Future Benefits

• Middleware
• Server Context
• Static data pre-generation
• Efficient sub-request caching
• Future RSC support in Remix
• More granular revalidation

Background

When a document request is made to Remix today, it calls all loaders in the same request, takes every response returned from loaders and attempts to merge them into a single response, and finally returns the document.

When the user navigates to another page with client side routing, Remix decides which route loaders to call an then makes a fetch from the browser for each loader in separate requests.

Problems

Today

• Inconsistent data fetching behavior between document requests and client side requests
• Each URL has the current URL + the route ID in a search param. This shards any CDN and browser HTTP caches for parent routes that aren't sending different data (since they don't (and shouldn't) typically care about the child portion of the URL).
  • Instead of a route growing the cache by the size of its own data, it's a cartesian product of the size of it's own data and the params of its child routes.
• Merging headers/cookies is a bit confusing and works differently depending on the type of navigation (document vs. data)

In the future

As we explored middleware, we weren't satisfied with the behavior that would be required to support it with the current data fetching behavior. A single middleware would be called multiple times for the same client side navigation. This is unintuitive and inefficient.

Being able to anticipate a single request per navigation will make several other future features easier to implement and use. For example, Remix could provide ways to share data between loaders (and even middleware) so that code naturally avoids making the same calls to the data store twice even if the application code looks that way.

Proposal

Future Flag

Turning on a future flag will enable the new behavior:

{
  future: {
    unstable_singleFetch: true;
  }
}

New Behavior

• Instead of making client side fetches for every loader, Remix will make a single fetch for all data
• The URL will no longer have the route ID in a search param, but simply the URL + .json on the end and an X-Remix-Data header.

API Changes

• Loaders and actions can no longer return Responses, but instead simply return data.

• Data functions set headers with a new headers param passed to them.

  export function loader({ headers, status }) {
    let [stuff, dbTime] = myTimingFunc(() => myDb.stuff());
    headers.append("Server-Timing", `db;dur=${dbTime}`);
    return stuff;
  }

• The headers export is no longer used and no application level merge is required anymore.

• Data functions receive a new status function to set the status of the response. The last route to call this wins.

  export function action({ request, status }) {
    let [errors, record] = await createThing(request);
  
    if (errors) {
      status(400);
      return errors;
    }
  
    return record;
  }

  A function can be used to get access to the status any parent routes may have set:

  status((parentStatus) => {
    if (parentStatus >= 400) {
      return parentStatus;
    }
    return 200;
  });

  Though loaders are still called in parallel, the status function will be deterministically called in order from parent to child.

• Instead of throwing Responses, data functions throw a new BadResponse(). The values passed to the constructor will be available in the ErrorBoundary with useLoaderData.

  export function loader({ headers, status }) {
    let stuff = await myDb.stuff();
    if (!stuff) {
      status(404);
      throw new BadResponse({ message: "Not Found" });
    }
    return stuff;
  }

• deprecate useRouteError, but it will continue to return the same thing as useLoaderData inside of an ErrorBoundary.

• deprecate isRouteErrorResponse, error boundary components can simply ask if data instanceof BadResponse.

Revalidation Behavior

Today's Behavior

Today the fetches Remix makes on navigations is determined by the changing routes and the shouldRevalidate exports of all routes.

• By default, only the changing routes are revalidated on navigations
• If a changing route defines a shouldRevalidate, then the fetch is made if it returns true, or it can opt out with false
• Similarly, if an unchanging route defines a shouldRevalidate, then it has the potential to make a fetch if shouldRevladate returns true.

Future Behavior

• By default, All routes are revalidated on navigation, just like a normal document request. This is predictable, easy to understand, and consistent with the behavior of document requests. It also makes HTTP caching more efficient.

• Opt-in granular revalidation through shouldRevalidate is done through headers. Remix will avoid calling loaders that are not present in a custom header. While some intermediate caches don't work well with headers, they are different optimizations with little (if any) practical overlap: if you are able to use CDN caching of an entire document, you won't need granular revalidation of individual loaders and visa versa.

• URLs end in .json instead of a _data search param. This is easier for many intermediate caches to work with and also opens the door for static pre-fetching (Files can't have search params, but they can have .json, allowing the Remix runtime to fetch pre-generated data files from the public directory, making SSG a very quick script away for folks who want it)

---

While this might not seem like a huge win on the surface here is a summary of the benefits:

• it closes some inconsistency between document and data requests
• easier for developers to understand how Remix works (and simplifies Remix internal code)
• is more predictable for CDN and other intermediate caches
• simplifies headers with nested routes

Closing that inconsistency gap also enables these future features:

• middleware
• sub-request caching for more optimized servers
• static data prefetching (used in conjunction with SPA targeting, provides full SSG)
• aligns current APIs more closely with future RSC support

[sergiodxa]

Loaders and actions can no longer return Responses, but instead simply return data

What happens in resource routes? They will still need to return responses, right? This will cause an inconsistency, unless there's a separate export (not a loader or action) for resource routes, like

export async function handler({ request }: DataFunctionArgs) {
  return new Response();
}

That can work for any HTTP method.

[ryanflorence]

Great question, I like what you've suggested, or even just the default export.

[sergiodxa]

I was thinking default export too, but then Remix will need to differentiate them from a component.

[ryanflorence]

a good point, would even simplify how we detect resource route vs. not resource route

[brophdawg11]

Interesting - so resource routes would no longer have loader/action and would instead just use handler? I like that.

[KevinMind]

Could we avoid this by allowing loaders/actions to return a response? If a loader/action returns a response it is a resource route, if not it is a route?

Or have a custom Function return like return ResourceResponse()?

export async function loader({request}) {
   // resource loader
   return ResourceResponse(pdf);

   // data loader
   return data;

   // error loader
   return BadResponse(response);
}

One issue here is the typings of loader/actions have to account more types of return values, and theres a relationship between what types are expected and the exports of the file.. might be kinda wonky.

But I'm not sure if having a handler method makes it much better. What happens if there is an exported handler and a default export component? Is it a resource or a component route?

[sergiodxa]

Will this include a dataloader for shared data like we once talked about? If I remember correctly it was something kinda like this:

export async function loader({ load }) {
  let result = await load(async () => {
    // do the fetch here
  })
}

[ryanflorence]

When we ship RSC, yes, not sure if we'll do it before though. But you're now able to implement your own and it'll actually work w/ a single fetch.

[sergiodxa]

I'm not completely convinced of ditching the simple request -> response flow of loaders and actions.

Is there no other way to achieve the same benefits without losing that?

[ryanflorence]

The motivation here is two things for me:

• Primary motivation is for document/data request consistency: there's no more "sometimes this response is sent, sometimes it's merged with other responses" and all of the complexity and problems that causes. I simply wish we had done it this way initially because the merging stuff has been a pain for remix and remix apps, and caused many problems for caching with CDNs, redis, kv stores, etc.

• In the future, server components will receive data straight from the source that loaders get data from without a serialization/request/response cycle in the middle. The indirection is removed in RSC and with it the need for a response. This change is a baby step to prepping Remix apps to be able to smoothly adopt RSC where it makes sense. Setting headers, etc. will be the same in Remix pre-rsc and post-rsc, you'll simply inline loader code into the route component.

[rossipedia]

you'll simply inline loader code into the route component.

😭

[JClackett]

Yeah im liking the sound of just returning the raw data! then just dragging it down into the component post-rsc!

[ngbrown]

The example of headers.set("Server-Timing", db;dur=${dbTime}); is given, but possibly every loader and middleware on a request will want to set their portion of that header to result in a single merged Server-Timing header. Right now my application code performs that merge.

In this example, would each data function be responsible for the merging its self and actually need to use the .append method?

headers.append("Server-Timing", `db;dur=${dbTime}`);

[ryanflorence]

Yeah, no need to merge, just headers.append. I edited the post to use append, thanks!

[afoures]

This is interesting, but I wonder how defer would work with this single data fetch RFC?

And what about testing and mocking (like using MSW)? Seems like some stuff will change with this

[ryanflorence]

Indeed, it's a breaking change so any tests that were concerned with the implementation details of Remix's fetches will need to adjust to the new format.

I don't anticipate defer will be any different., we're just sending multiple bits of data in a single response and the deferred bits will look and work just like they used to inside of that.

[mrksbnch]

How will the opt-in granular revalidation work in detail? Can I still control (via a custom header) what loaders get revalidated? For example, will it still be possible to fetch data in a parent loader (used via "usedRouteLoaderData" in child routes) and prevent revalidation for this particular parent loader for normal document requests?

[sergiodxa]

Note that Remix hooks like useRouteLoaderData doesn’t do any fetch and doesn’t affect how data is fetched, they just gives you access to the data Remix already has in its internal context.

[mrksbnch]

Thanks, I'm aware that they only give access to data from a particular loader. But I agree that my question (specifically the word "fetch") was poorly worded. I was just wondering if and how I can control what loaders run for specific requests. I have various use-cases where I don't want certain loaders to get revalidated for some form of document requests.

[kiliman]

The current RFC appears to imply that ALL loaders will be revalidated on every navigation, unlike today where common ancestor loaders are NOT fetched, like root or parent route.

Perhaps Remix can call shouldRevalidate on client-side navigations, then include headers in the request that it can use to know which loaders to call on the server. Returned data will only update loaders that were actually called, and existing loader context will be maintained for those that are not called.

Something like

GET /parent/child.json
X-Remix-Revalidate: root=false
X-Remix-Revalidate: parent=true

{ 
  "root": null,
  "parent": { ... parent data },
  "child": { ... child data }
}

[brophdawg11]

This is addressed at the very bottom of the RFC, very similar to what you've proposed here

Opt-in granular revalidation through shouldRevalidate is done through headers. Remix will avoid calling loaders that are not present in a custom header. While some intermediate caches don't work well with headers, they are different optimizations with little (if any) practical overlap: if you are able to use CDN caching of an entire document, you won't need granular revalidation of individual loaders and visa versa.

[lifeiscontent]

@ryanflorence would single data fetch solve the issues for things like flash messages being cleared out?

e.g. I have a flash message session that is read at the root loader but in order to clear out the session on page transitions I must do it within all subsequent loaders in the scenario that the root loader doesn't run.

[buzinas]

IMO this would be solved by middleware.

[ryanflorence]

Yes it will because there's only one request and I race conditions on setting the cookie. But as @buzinas said, middleware will probably be a better spot

[romansndlr]

• This is a massive breaking change that will break every loader ever written. From my prospective, feels like very low ROI to make this migration.
• I feel like this makes the concept of loaders way more "magical" in a bad way... While teaching current Remix, it was very clear to my peers that loaders are simply http endpoints that return http responses. Looks like with this approach it requires way more hand waving to explain how they work.

[jorisre]

I completely agree. As of now, I really appreciate the simplicity of Remix, just sticking to the standard Request/Response. Even though I understand the issues addressed by this RFC, I feel it complicates usage and abstracts away too much from the Web standards.

[brophdawg11]

This is a massive breaking change that will break every loader ever written

This is not accurate. The goal is that you do not have to change anything immediately. If you are returning json(), we'll unwrap the JSON and merge it into the single-fetch Response. Same with defer. Same with any other type of Response. The new preferred approach will just be returning raw data but you can update your loaders over time and you do not need to update them as soon as you opt-in.

Even better, with this new single-fetch Response we're also investigating a new streaming format that removes the JSON limitations. Want to return a Map? A Set? A Date? Go for it!

[Mange]

Sure, in the simple case. But didn't the proposal also claim that you cannot return a custom status code anymore, and that children's status code will overwrite the code of their parents.

That surely means that we must change some things, right?

function parentLoader() {
  if (Math.random() > 0.5)
    return json({state: "missing"}, {status: 404});
  return json({state: "ready"}, {status: 200});
}

function childLoader() {
  return {hello: "world"};
}

Which status code will these requests get?

fetch("/parent.json"); // 404
fetch("/parent/child.json"); // ???

Seems like the only way to get status back consistently now is to always, in each loader, check if the parent returned a code different from 200 and then pass it along. And still this would mean you "infect" child routes with the status code of parents.
In the example above, child would always be 200 and parent could be either 200 or 404, but if you blindly pass along parent status code then the child route also becomes 200 | 404.

[EDIT]: This concern was covered in another thread: #7640 (reply in thread)
I humbly suggest making this clearer in the proposal. I'm waaay less worried about this change now. 🙂

[PuruVJ]

Want to return a Map? A Set? A Date? Go for it!

Bit of an aside, devalue can be used for this, its used in SvelteKit and Nuxt as well, and serializes promises as well.

[sergiodxa]

@PuruVJ the team already built and used jacob-ebey/turbo-stream, which is based on a devalue

[smerchek]

A couple points of concern around status/header handling:

1. Imperative/mutation style for setting headers/status: I really like the current declarative style of setting these as part of the return. It makes it quite clear what's being sent and obvious if the values are missing. When they are set in this manner, I could see issues where it's not obvious which code path is setting the headers, or the call to set the correct status was forgotten.

2. How to handle redirects? Would throw redirect(...) still work like the throwing of BadResponse? A common pattern we have is for loaders like thing.$slug.tsx is:

const thing = await getThingBySlug(slug)

  if (!thing || thing.isDeleted) {
    throw notFound({ message: 'Thing not found' });
  }

  const actualSlug = thing.slug;

  if (slug !== actualSlug) {
    const url = new URL(request.url);
    const redirectTo = url.pathname.replace(slug, actualSlug);

    throw redirect(redirectTo);
  }
  
  return { thing }

Would the proposal be to manually set status(301) and headers.append('whatever the proper redirect headers are')?

Maybe a wrapper or v1-compat helps this situation where any thrown Response still works but just does the 2-3 steps of headers, status, and data return for you?

[smerchek]

Maybe this is solved with Middlewares? #7642 I may need to just step back out to look at the RFCs together/more holistically

[ryanflorence]

Throwing will work the same.

I hear you on the mutation style stuff but I think it's less confusing and easier to build abstractions for than merging four responses together for documents in the headers export (which nobody seems to do and they probably aren't sending the headers they think they are), and letting them just do whatever for client navigations.

I just think of it like setting headers in my old PHP days, so easy. If back then I had to think about iterating a list of parent headers and performing a merge I could t have done it. The mutation API I think is easy to do, easy to build abstractions for (like middleware after this), and once we're in RSC territory, the only way afaict.

[Mxs2019]

Two questions

1. I’m still not entirely clear how redirects work. Do you throw a redirect or set a header and then throw or something?
2. Does the meta api change at all with this change?

[gustavopch]

First question was answered here: #7640 (reply in thread):

Throwing will work the same.

[ryanflorence]

The only thing that changes here are the implementation details of how we fetch. If you're using cache-control headers, the caching behavior will be different (and will be much simpler and more efficient). If you're not using cache-control headers in your app, then you might not even notice we changed anything.

[frontsideair]

Why not send data request with Accept: application/json header and use content negotiation instead of .json extension with custom header? Serving statically generated json files from the filesystem is a good, but I believe it'll be easy to strip json extension. Preventing easy scraping is possibly a reason, which explains the custom header, but it's easy to bypass for a slightly determined scraper.

[sergiodxa]

Using content negotiation may cause http cache to incorrectly send html or json in some CDNs if Vary header is not set or even supported at all by the CDN, that’s why it currently uses the _data search param, this change the search param with the extension which will still give you a different url for CDN caches to work properly.

[frontsideair]

This is unfortunate but understandable. I would expect CDNs to be more pedantic about spec compliance than most but here we are.

[justinwaite]

I'm a little concerned/confused about the "waterfall" of status checking.

Given this deep tree of child routes

- route a (200)
  - route b (200)
    - route c (400)
      - route d (200)
        - route e (200) 

Am I understanding correctly that unless route d and e check the parent status c, then the 400 status set by c could be overwritten? I feel like this is something that could (accidentally) be easily omitted in the child routes. If a parent route throws a non-2xx code, I feel like it should take precedence over a child route's status.

I think this affects refactoring and code portability as well – a child route shouldn't have to "know" about it's parent route's possible status values. I also don't want to have to stick this chunk of code in 100% of my route loaders.

Then again, I could be misunderstanding the intention and/or the actual desired implementation, in which case you are free to ignore me 🙃

[justinwaite]

@ryanflorence thank you for that clarification! Consider my concerns alleviated in that regard.

[frontsideair]

I came to write the same, but upon closer inspection "waterfall" in-quotes tripped me up too. If I understand correctly, it's about how it's child loader's obligation to check parent loaders' status.

My understanding is, if you don't call status on child loaders parent will win, but your concern is valid in case you're using statuses extensively, it's a bit cumbersome to check parent status in every child loader.

But I guess throwing will work the same, so if you want to return 404 from a parent loader and you don't want a child loader to mess with it, you can throw the response as before.

[justinwaite]

The code example in the proposal did make it seem like it was the child's responsibility to check for the status of it's parent.

This example in particular:

status((parentStatus) => {
  if (parentStatus >= 400) {
    return parentStatus;
  }
  return 200;
});

I'm sure there are specific use-cases for this, but I didn't understand the point of even checking for the parent's status code.

[ryanflorence]

It's really just making our client navigation fetches use the same code as document requests. Today they branch and are handled differently. It will lead to more consistent http caching and unlock future features we can't do with individual fetches.

[msakrejda]

But the example itself is kind of misleading, no? If we never get to the child when a parent has set a non-2xx status code, what's the point of checking if parentStatus >= 400?

[ZeldOcarina]

I feel this is abstracting a bit too much from Remix current behaviour and feels like a super breaking change that would make basically all past apps completely unusable. Still, I see the issues the current setup is creating to convert to RSC or to implement middlewares so I understand where this is coming from and I appreciate your careful considerations.

What I am concerned, if a full breaking change is absolutely needed as you are well explaining in the RFC, is the API is a little hard to grasp.

In my small experience, after trying a lot of frameworks, the best at actually handling server-side requests, is Express. In its simplicity it just does everything is needed, from middlewares to error handling and it lets you send any response you want. Its syntax is also globally appreciated by JS developers, every time you move to a JS meta-framework, it seems like you need to sacrifice a bit on the backend not using Express in its simplicity.

I'm not sure how to implement this, but, if we need to completely revolutionise loaders, I feel going to a more Express-like syntax would be beneficial.

i.e.:

Adding the possibility of ending the request immediately and ditch any subsequent loaders in any of the loaders by returning res.status.send or res.status.json.

res.status(201).json({status: "success", data: "user successfully created"});

Being able to call next() in middlewares or in any loaders to throw Errors that can be then caught in a global error middleware.

These are the parts I feel are missing the most in Remix right now and going back to Express and leverage is well estabilished and known syntax might be a nice way of making Remix more inviting for backend devs too.

[sergiodxa]

If Remix followed a similar pattern to Express where you use next to call middleware and other loaders, that would make all loaders run serially instead of in parallel, currently all loaders run in parallel and that will remain untouched with this RFC.

Only middlewares will run serially but they are a separate proposal.

---

BTW I'm with you this will be a big breaking change (basically all loaders will need to be changed) and while I get the benefits (type-safety will be simpler since you return a raw value instead of a response, Remix will more easily combine responses into a single data, etc.) I'm still not 100% sold on this change.

[brophdawg11]

super breaking change

This is inaccurate. The goal of the implementation is that all of your loaders today work without any changes. Over time you can stop using the json/defer Response helpers and just return raw data but you shouldn't need to do that to opt into single fetch. As we get even closer to a v3 stable release we'll also likely add some deprecation warnings to loaders that return Responses so you know which ones still need to be converted ahead of a v3 upgrade.

We are very conscious of providing smooth and iterative upgrade paths for our users 😄

https://remix.run/blog/future-flags

[ZeldOcarina]

Hi @brophdawg11 thanks for your feedback, I'm glad of the consciousness used!

[ivosabev]

Maybe there should be a way to opt-out of merging for a specific routes/loaders? This could be the same mechanism used in API routes as well.

For example if the loader returns a new Response() do not merge it an call it separately.

[brophdawg11]

This isn't possible since the client needs to decide whether to make one or multiple calls. It would be impossible to make that decision based on a return value from a not-yet-called loader.

[ivosabev]

Regardless of the actual solution, if there is no such option, how could different loaders have different cache requirements and headers?

[brophdawg11]

Two sections of the RFC are relevant here:

• "Data functions set headers with a new headers param ..."
• "Opt-in granular revalidation ..."

Loaders will be able to set individual headers. And depending on shouldRevalidate, different sets of loaders will be called within the fetch which may result in different cache behavior.

[blittle]

A few commerce use-cases to keep in mind:

1. Many ecom sites have content that is mostly cacheable, except for the "logged in user" and cart. The data for these could easily be loaded via clientLoader. This would make the entire page cacheable, and the subsequent data fetch also easily cacheable. All the new revalidation logic and simplified approach would be better. 🎊
2. Other more advanced ecom sites are extremely dynamic. Even the core structure of the page (available menu links, collection page layout, structure of the PDP) can be different based on the identity of the user. In these scenarios, the document request and subsequent data requests cannot be cached. We heavily rely on sub-routing revalidation logic to enhance performance. These changes mean by default page transitions would degrade in performance. Perhaps for these types of dynamic sites (probably also similar for login apps like Shopify admin), it might be nice to have an easy way to re-enable fine-grained revalidation logic.

[brophdawg11]

it might be nice to have an easy way to re-enable fine-grained revalidation logic.

Check out the very bottom of the RFC ("Opt-in granular revalidation through shouldRevalidate is done through headers") - does that alleviate this concern? A bunch of folks (myself included) missed this on the initial reading of the RFC :)

[blittle]

I see that, but it's not clear to me if I need to manually go through and define shouldRevalidate logic everywhere, or if there would be an easier way to retain the previous revalidation logic?

[brophdawg11]

ah ok yeah makes sense. Yeah I think the plan is that you will need to manually add some more shouldRevalidate functions in the future to get the same "optimizations" Remix gives you today.

[blittle]

That's where I wonder if it's worth offering an easier approach. Because most authenticated apps (like Shopify admin for example) are not going to take advantage of almost any edge caching. Instead the existing revalidation logic is important. I'm trying to say, I don't think there's a one-size-fits-all approach.

[rubber-duck-software]

Let me check my understanding here.

A Response is constructed with 4 things. Remix is proposing the following method to assemble a Response

1. body (see https://developer.mozilla.org/en-US/docs/Web/API/Response/Response#body)

The body will be returned from the loader. Will be of type BodyInit

2. headers

A Headers object will be passed as an argument to the loader. The loader is free to mutate the headers

3. status

status is set using a status callback which is passed as an argument to the loader.

4. statusText

Remix is not proposing supporting at this time.

[gustavopch]

Worth mentioning:

Note that HTTP/2 does not support status messages.
– https://developer.mozilla.org/en-US/docs/Web/API/Response/statusText

[rubber-duck-software]

Great callout! In HTTP/2 a response is constructed with only 3 things.

[richardscarrott]

Our client side navigations are currently benefiting from having independent fetches because the data returned from each loader has different freshness requirements.

For example, our ecom PDP page is constructed like this:

GET /products/my-product

├── root.tsx
└── routes
    ├── _store.$locale.tsx
    └── _store.$locale.products.$handle.tsx

Where

1. root.tsx loads translations
   • max-age=3600
2. routes/_store.$locale.tsx loads user + cart
   • no-cache, must-revalidate
3. routes/_store.$locale.products.$handle.tsx loads product data
   • max-age=86400

This makes navigating from PLP to PDP etc. very quick because it only revalidates the changing route (3.) which is cacheable.

In order to maintain this benefit, I'm guessing we'd a) need to implement the revalidation custom header proposed in this RFC and b) set a vary header to ensure caches treat them as separate cache entries? I wonder, what is real-world support like for the vary header across different browsers and CDNs?

If it's not supported well enough, then perhaps Remix could also support accepting the value as a query param to the .json endpoint?

[brophdawg11]

You wouldn't need to implement the custom header specifically, just provide shouldRevalidate functions at the route level. The custom header would be an implementation detail that Remix would use based on your shouldRevalidate functions

[kasperpeulen]

Will this feature flag also be available in react router somehow?

https://reactrouter.com/en/main/route/loader

[brophdawg11]

Probably not out of the box but you'll likely have the API surface to implement it on your own. React Router will likely allow you to provide your own "fetch strategy" implementation (instead of the default "fetch in parallel" used today). Remix will then provide it's own implementation to achieve single-fetch - and you'd be able to probably grab a modified version of that and provide it in your React Router app (or write a specific one for your use case).

[lstanden]

Borrowing from ideas in react-admin and refine, have you considered an option for a more opinionated declarative data loading mechanism that would roll up client calls to the server more gracefully?

This would allow you to do some pretty cool stuff if you're using (for example) a GraphQL API behind the scenes

// posts.tsx
export function hybridLoader() {
    return useGetList('posts', [ 'id', 'title' ]);
}

// posts/$id.tsx
export function hybridLoader({ params }) {
    return useGetOne('posts', params.id, ['id', 'title', 'prose'])
}

Behind the scenes, a data loader for a GraphQL API could translate that into the following example query:

query example(id: ID!) {
    posts {
        id
        title
    }
    post(id: $id) {
        id
        title
        prose
    }
}

Now the client version of this can roll up multiple calls to these resource functions and send it in a single round trip.
At the same time, the server can have something at the top level gather all the resource requests and do a bunch of useful things. Some things that come to mind:

• Translate many getOne calls into a single getMany call, effectively making it a SELECT * FROM Table WHERE id IN(:ids)
• Potentially combine queries where in a composition, many components ask for the same resource
• Stream results as they become available
• etc

[brophdawg11]

You'll be able to do this via the React Router side: #7640 (reply in thread). At the moment, I there's no plan to expose that level of customization to the Remix side though. It feels like something you may be able to do via middleware eventually though.

[okalil]

I see the benefits of this new approach, but I feel like we are moving away from the "use the platform" philosophy by creating those special status and BadResponse functions.

My proposal would be the following (I would like a feedback if it makes sense):

1. Instead of using headers and status function, we would get a mutable responseOptions (based on ResponseInit interface) (or responseInit)

export function loader({ responseInit }) {
  let [stuff, dbTime] = myTimingFunc(() => myDb.stuff());
  responseInit.headers.append("Server-Timing", `db;dur=${dbTime}`);
  return stuff;
}

2. You can modify status property in responseInit

export function action({ request, responseInit }) {
  let [errors, record] = await createThing(request);

  if (errors) {
    responseInit.status = 400
    return errors;
  }

  return record;
}

3. I don't like the check parent status thing, I think that should be automatic (maybe the biggest status win 400 > 200 (not sure it fits all cases though)). Anyways, this probably could still be made by getting the status value.

const parentStatus = responseInit.status
if(parentStatus < 400) responseInit.status = 200

4. Instead of creating a new API BadResponse, we continue using Response

export function loader({ responseInit }) {
  let stuff = await myDb.stuff();
  if (!stuff) {
    responseInit.status = 400
    throw Response.json({ message: "Not Found" }, { status: responseInit.status });
  }
  return stuff;
}

[mrksbnch]

Isn't your proposal very similar to what the new approach will look like?

• Actual data is returned instead of a Response.
• You use responseInit.status and responseInit.headers to set headers and a status. The proposal is very similar but instead only exposes status and headers (which is all that you need).

The only somewhat bigger difference is throwing responses. The BadResponse may not be perfect but IMO better than having to set the status twice (in responseInit and the thrown Response).

I don't like the check parent status thing, I think that should be automatic (maybe the biggest status win 400 > 200 (not sure it fits all cases though)). Anyways, this probably could still be made by getting the status value.

Based on some comments above, you don't necessarily need to do check the parent status: #7640 (reply in thread)

[kiliman]

True, but I don't think a minor inconvenience (duplicating status) is worth having to learn another API. ResponseInit is already a standard API.

Frankly, I would prefer to continue to return responses like the current Remix. It made it simple to teach. "In Remix, loaders and actions receive a Request and return a Response."

Yeah, I didn't read through all the comments. If you have an RFC and people comment, it would help to update the main post with clarifications or updates.

[okalil]

Yes, it is

• You use responseInit.status and responseInit.headers to set headers and a status. The proposal is very similar but instead only exposes status and headers (which is all that you need).

The difference is how you do it. The status function would be a new Remix API, responseInit would implement ResponseInit interface, which is a standard way to construct Response objects

The only somewhat bigger difference is throwing responses. The BadResponse may not be perfect but IMO better than having to set the status twice (in responseInit and the thrown Response).

Even though I explicitly added the status to the thrown Response, Remix can do that under the hood
(btw, you could even pass the whole responseInit to Response, like Response.json({ message: 'Not Found', responseInit)

[sergiodxa]

I like this idea of receiving the ResponseInit object and mutating it. It feels a little bit more like Express where you received a res object but at least it remains more similar to the web platform

[robertjpayne]

I totally agree. One of the things I don't like about Next.js is the weird functions they have to set headers, cookies, etc.

As for parent status, Remix already handles it automatically for you for document requests. The leaf status wins unless a parent loader returns non-200. I think that's sensible.

If you really need to share status/data across loaders, then use the Server Context API.

Without single-fetch Server Context API's are not workable for client navigations because the loader requests may be scaled out horizontally.

[PatrykWalach]

How would this work with clientLoader, when there's now way to tell if and when the serverLoader gets called?

// root.tsx
export const clientLoader = async (args) => {
  await sleep(10_000)
  return await args.serverLoader()
}

// _index.tsx
export const clientLoader = async (args) => {
  return await args.serverLoader()
}

[kiliman]

I imagine it will work just like server-side document requests where all loaders are called in parallel via Promise.all

If you export a clientLoader, it will await the promise. Whether it calls the serverLoader or not, it still has to wait for the results.

[cha0s]

I might be misunderstanding something, but does this mean that longpolling and/or Server-Sent Events will no longer be possible? Both cases are achieved only by directly controlling Response through e.g. ReadableStream. Are you abandoning streaming responses?

[brophdawg11]

RFC's reflect our initial ideas and proposal. Unfortunately, it's near impossible to keep them updated with every piece of feedback we receive from the community and every decision we make along the way as we go through implementation. We always aim to document the final state in the documentation with the released feature - you can preview the upcoming 2.9.0 documentation here

[cha0s]

No worries! I'm relieved that they will continue to work. I don't intend to create more RFC busywork, I just thought I'd share the source of my confusion. Thanks!

[janhesters]

@brophdawg11 Does that mean that json will only be deprecated for UI routes, but will stay in Remix V3, so we can still use it for resource routes?

And do resource routes still return new Response objects?

[kiliman]

I imagine so since Resource Routes, by definition, return responses directly and bypass Remix handling.

You should also be able to do return Response.json(payload) if they deprecate the json helper.

[brophdawg11]

Yes - Resource Routes will always be able to return Response instances.

Whether or not Remix will continue to export a few-line json utility is up in the air but as @kiliman pointed you you could use Response.json and I also think that if we dropped it, @sergiodxa would likely add it to remix-utils.

Be aware though that in some cases, you may not want to return a response - like when hitting a resource route from a fetcher - we made some recent changes around this behavior (not shipped yet) but here's the updated docs on the dev branch: https://remix.run/docs/en/dev/guides/single-fetch#resource-routes

[ersinakinci]

O Lords of Remix:
do not go down this dark path.
In winter comes Next(.js)

[ersinakinci]

Embrace the simple;
perfection lures the summer
fish onto the hook

[ersinakinci]

Bottles float; their necks,
constricted by complex code,
strangle the message

[ziimakc]

Nice, managing session headers was troublesome. Hopefully it will also resolve socket hang up issue.