Proposal: Add new Route Module export called actionLoader

[kstoddard]

Proposal: Add new Route Module export called actionLoader

A new method called actionLoader which acts as a reducer, taking the last state of the loader, the result of the last action, and then computing the next state of the loader. In this scenario, the data revalidation process is handed over to developer.

TL;DR

Add support in Remix to be able to take the result of an action (POST, etc.) and use it to satisfy the result of a loader (GET).

The Remix loader / action conundrum

In Remix, when an action runs successfully, one or more loaders will rerun (depending on the URL and layout) to keep UI state in sync with server state. The process is outlined here:

https://remix.run/docs/en/v1/guides/data-writes

When the user submits the form, Remix will:

1. Call the action for the form
2. Reload all of the data for all of the routes on the page

Remix knows how to load the data as well as how to revalidate it after it changes when you use standard HTML APIs.

The problem

Remix's data revalidation process requires at least one additional request (sometimes more) every time an action is taken.

Many times an updated resource can be sent back in the same request but given Remix's current process there is no way to take the data returned from an action and hand it over to the loader.

If a loader reaches out to multiple API endpoints but only a single representation changed, developers are left to implement a caching layer like Redis (which is fine, we need to do that anyway at some point) to make sure that we don't run up against rate limits and other potential bottlenecks related to extra API calls.

Example: mutations that happen from a collection of resources

Often, web apps will pull in collections of resources, for example:

• Tickets
• Products
• Users

Let's look at the "tickets" example. Consider the list view in a ticket system that contains quick actions from each item. Every time an action is taken on an item, the loader has to rerun to ensure that server state matches UI state. Imagine a scenario where ONLY the state of the individual ticket changed, it seems unnecessary to reach out for the entire list after each action when it can be returned in the successful POST request.

In other words, we don't want to GET /tickets every time POST /tickets/123/comments is successful.

What about unstable_shouldreload?

See: https://remix.run/docs/en/v1/api/conventions#unstable_shouldreload

This API handles the "never run more than once" scenario which is a solution to another problem entirely.

This proposal is not about never rerunning the loader but rather, about having a way to instruct Remix what to reload based on the result of an action.

Is there already a better way to handle this problem?

Part of me wonders if this problem can be solved another way by restructuring our routes, if you have ideas please share.

The Remix Way

The Remix revalidation process may be the best way to handle this problem, it ensures that UI state and server state align. It seems like the simplest way to guarantee things are correct. However, in my discussions with BE devs, there is still some concern around extra round trips to the server both from HTTP level and a server resource level. Both HTTP and server-side caching are solutions we are looking at but they don't entirely address the problem.

At the end of the day, I am fine with The Remix Way because it is pretty much equivalent to how the browser works without JS enabled (progressive enhancement FTW). But still.

Web Standards ❤️

In looking at the HTTP spec, given this proposal, I think Remix may be able to align a little more closely in scenarios when the "best" thing to do would be to respond with the new representation obtained from the action (i.e., POST requests returning 200 OK...not to abuse this status code but it seems right in this case). Consider...

The 200 (OK) status code indicates that the request has succeeded. The content sent in a 200 response depends on the request method. For the methods defined by this specification, the intended meaning of the content can be summarized as:
...
| POST | the status of, or results obtained from, an action
...
See: https://datatracker.ietf.org/doc/html/rfc9110#section-15.3.1

As an aside, though it doesn't solve the problem this discussion is about, there are some instances when the "round trip" back to the server to validate can actually be satisfied from the cached result of a POST.

Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of [CACHING]) and a Content-Location header field that has the same value as the POST's target URI (Section 8.7). A cached POST response can be reused to satisfy a later GET or HEAD request.
See: https://datatracker.ietf.org/doc/html/rfc9110#section-9.3.3

This is not common but seems like a reasonable means to forego the second trip out to the server. Methinks this is possible already in Remix, just return the appropriate cache-control headers in your response from an action. Subsequent GET requests should already be satisfied.

Benefits

• Performance gains
  • Reduce network round trips
  • Decrease server load
• MAY reduce app complexity
  • App level caching like Redis may not be needed as often. Again, looking at the scenario where the loader may have to hit more than one endpoint to collect data.

Related discussions

I looked around a bit to see if anyone was talking about this, doesn't appear to be much discussion, though there is some. Not sure about Discord, I took a peek but search didn't turn up much.

• Bypassing refetch using action data #3176
  • Same issue/problem, different discussion
• Remix Revalidation and non-ACID databases (Cloudflare KV) #2817
  • Not particularly related but this proposal may benefit

Final note

I realize that some of the ideas in this proposal may not be plausible just due to blind spots and/or lack of knowledge of the HTTP spec and Remix as a framework. Feedback is very much welcome.

[kiliman]

I think part of the issue is that some of your concerns can be mitigated by adjusting your route structure as well as judicious use of unstable_shouldReload.

In your Tickets example, you have a nested route of /tickets/123/comments. Assuming that the /tickets route returns a list of tickets, unless that list is being rendered on that route, I would not make it a nested route. Instead use /tickets.$ticketId.comments. A flat-file layout removes the parent loader as a dependency. https://remix.run/docs/en/v1/guides/routing#nested-urls-without-nesting-layouts

Even if your layout had a list of tickets in the left nav, and adding a comment won't change the ticket title, etc. use of unstable_shouldReload could check if the submission was for comments and return false. https://remix.run/docs/en/v1/api/conventions#unstable_shouldreload

I'm not sure where you got the "never load more than once" idea from, but this function receives all the data you need to make an informed decision for every revalidation. You can return true/false for each scenario that is appropriate.

import type { ShouldReloadFunction } from "@remix-run/react";

export const unstable_shouldReload: ShouldReloadFunction =
  ({
    // same params that go to `loader` and `action`
    params,

    // a possible form submission that caused this to be reloaded
    submission,

    // the next URL being used to render this page
    url,

    // the previous URL used to render this page
    prevUrl,
  }) => false; // or `true`

Anyway, for this proposal to gain any traction, I think you're going to have to create some real use cases. Show how current Remix is inadequate, cumbersome, inefficient, etc. And how this idea is novel and worth incorporating. The main concern is that you will introduce additional concepts beyond existing revalidation/shouldReload mechanics, and are those concepts worthwhile?

That's my 2c. Feel free to ask questions if needed.

[kstoddard]

Thanks for the response, I'll follow up with some additional context if necessary once I've taken a deeper look at your feedback. Also, you are correct about this (my mistake, I did know this, just somehow failed to consider it, which indeed may be all we need)...

I'm not sure where you got the "never load more than once" idea from, but this function receives all the data you need to make an informed decision for every revalidation. You can return true/false for each scenario that is appropriate.

The main feature this proposal would introduce (in whatever form it took) would be the ability to take the response from an action and hand it off to the loader, thus reducing the need for another round trip to the server (in cases where it made sense). It would be very similar to unstable_shouldReload in that it only covers a few particular use cases. As I mentioned, I'll follow up with some more concrete examples once I've had sufficient time to consider your feedback. Thanks again!

[kstoddard]

Okay, I didn't expect to get back so quickly but I think you are correct, we can very likely enable what we are asking for in the proposal already with just the unstable_shouldReload export. It'd look something like this...

⚠️ WARNING Pseudocode below (mostly), it's just for illustration sake and written from memory in like 5m ⚠️

export const loader = async ({ request }) => {
    const tickets = await getTickets();

    return json({ tickets });
}

export const action = async ({ request }) => {
    const response = await mapPostRequest(request); // Business logic/processing (stuff)

    return json(response);
}

export const unstable_shouldReload = ({ submission }) => (
    submission.ACTION === 'UPDATE_TICKET' ? true : false // Idk, whatever, just need to inspect the submission
);

export default function Tickets() {
    const loaderData = useLoaderData();
    const actionData = useActionData();
    const { tickets } = actionData ? actionReducer(actionData, loaderData) : loaderData;

    return (
        // ticket list
    );
}

I'll follow up again once I have been able to test out this flow in an actual code example and verified that it works as described above. Sweet!