Refresh Route Data API

[ryanflorence]

It has become a common expectation in the React ecosystem that data fetching libraries have the ability to arbitrarily refresh their data at any time. It's most often used to revalidate the data on the page after a mutation is performed.

This isn't often needed in Remix since it automatically handles data revalidation after actions for you. However, there are several other cases where it would be useful to reload the route data on the page.

• Revalidating data when focus returns to the window
• Long polling as a quick substitute for websockets or event sources.
• Revalidating data across open tabs in the same app so that mutations occurring in one tab update the other tabs
• probably more, but I need at least three to justify the feature for myself 😉

This is possible today but with unacceptable side effects:

Many people will navigate to exactly where the user is at to trigger a reload of all routes:

function Comp() {
  let navigate = useNavigate();
  useWindowFocus(() => {
    navigate(".", { replace: true });
  });
}

This is bad because it will slice off the last entries of the history stack if the user isn't at the end of it (wipes out the "forward" button).

A better option is to submit a fetcher to get the routes to reload:

function Comp() {
  let fetcher = useFetcher();
  useWindowFocus(() => {
    fetcher.submit("/jk/who/cares", { method: "post" });
  });
}

This is better because it doesn't mess with the history stack, but it's silly because it sends off a pointless POST first, wasting resources and slowing down the process. All we want is the reload of routes afterward.

Since there are valid use cases, and it's already possible but with negative side effects, I'm proposing a new API here to add direct support for refreshing route data.

Proposal

The API is a mini useFetcher.

let refresher = useDataRefresh();
refresher.refresh();
refresher.state; // idle | loading
refresher.type; // init | refresh | refreshRedirect

I'd expect it to be used pretty simply:

function Root() {
  let { refresh } = useDataRefresh();
  useWindowFocus(refresh);
  // ...
}

You could add a global spinner to indicate the refresh:

function Refresher() {
  let { refresh, state } = useDataRefresh();
  useWindowFocus(refresh);
  return <Spinner show={state === "loading"} />;
}

Cross tab communication with BroadcastChannel:

// Set up the app to refresh when the other tab sends a "refresh" message
function Root() {
  let { refresh } = useDataRefresh();
  useBroadcastChannel("refresh", refresh);
  // ...
}

// Example of the component that broadcasts the refresh:
function DeleteRecord({ id }) {
  let broadcast = useBroadcastChannel("refresh");
  let fetcher = useFetcher();

  useEffect(() => {
    // tell the other tabs to refresh as soon as this tab starts to revalidate
    // data after the action
    if (fetcher.type === "actionReload") {
      broadcast("refresh");
    }
  }, [fetcher.type]);

  return (
    <fetcher.Form method="post" action="/delete/record">
      <button name="id" value={id}>
        Delete
      </button>
    </fetcher.Form>
  );
}

// Not Remix, just a quick idea for a hook that does this
function useBroadcastChannel(id, onMessage) {
  let channelRef = useRef();

  let post = useCallback(message => {
    channelRef.current.postMessage(message);
  }, []);

  useEffect(() => {
    channelRef.current = new BroadcastChannel("app-data");
    if (onMessage) {
      channel.addEventListener(id, onMessage);
    }
    return () => {
      if (onMessage) {
        channel.removeEventListener(id, onMessage);
      }
      channelRef.current.close();
    };
  }, []);

  return post;
}

Behavior

The revalidation fetches should be grouped with the useFetcher revalidations so that refreshes and fetcher revalidations will abort each other when reconciling race conditions.

Thoughts?

[sergiodxa]

Just to be sure, the idea is that because this hook has its own state and type it will not cause a change in useTransition right? So the useTransition values will still be tied to the global transition and this as with useFetcher will have another state right?

If that’s the case I think it makes sense since it’s not really transitioning anywhere.

I like the API, simple, not too much to comment, it does what I would expect.

[ryanflorence]

Correct, it's not a transition, just like fetchers, has it's own state, and just like fetchers, automatically coordinates race conditions w/ transitions/fetchers/refreshes so you always have the latest stuff from your server no matter how wildly your user clicks around.

[tchak]

What will happen if the device is offline/network fail when refresh is called?

[ryanflorence]

same thing as any other fetcher.load or link click. Error boundary?

[sergiodxa]

I don't think that should happen, because the data, even if it's old, it's already there on the UI, so if a refresh fail it could just fail silently and keep the old data until the user is back online and the next refresh works.

[BenMcH]

Keeping the stale data in combination with a property on the refresher indicating that an error occurred would be great from a DX perspective, I would think.

Then, the user on the page doesn't lose data that was previously visible if the network call fails while providing a mechanism for the developer to indicate that an error occurred to the user.

In its simplest form, the error could be implemented like this in the middle of a route containing a refresher

{refresher.state === 'error' && 'Unable to refresh data at this time'}

[ryanflorence]

I'm not sure about this one. I don't want error UI in my components, they are my happy place 😌

And I don't want to silently ignore them. One of the use cases is cross-tab or even multi-user notifications (web socket tells the other user to reload data). I can imagine a UI where the window w/ the mutations doesn't have a problem w/ the new data but some other window (or user) does.

[BenMcH]

Will this feature let me target a specific loader to re-fetch in the case of nested layouts? Or is meant to be a true 1:1 functionality replacement for navigate('.', { replace: true }) without the issues listed above?

[ryanflorence]

Route modules unstable_shouldReload would participate here just like any other time the routes are refreshed.

[afoures]

could we provide the info that the request was made via the refresher to unstable_shouldReload ?

[sergiodxa]

Another question about this, will the state be global?

If I call useDataRefresh on two components and one call refresh, should the other one also be able to see the state change?

I think it should, this will also allow apps to have a single UI to show the refreshing state and call refresh from another place.

[ryanflorence]

Ooh, good question. I was thinking of it like useFetcher where it has its own state. If multiple revalidations go out, they'll all be able to add updates as they land (and race conditions, ofc, would be managed)

If it's a "singleton" it can cancel the previous one in the case of interruption, but then you can't get updates along the way if multiple are revalidating at once.

I can go either way on this.

[brophdawg11]

What about navigation interruptions? There's a potential conflict between forced loader re-runs via useDataRefresh and normal loader skipping logic for reused route modules.

For example:

1. User navigates / -> /tasks/1
   • tasks loader runs
   • tasks/:id loader runs for id=1
2. useDataRefresh() called from /tasks/1 to refresh data
   • tasks loader does re-run since it's an explicit "reload everything"
   • tasks/:id loader re-runs for id=1
3. User interrupts useDataRefresh with a navigation /tasks/1 -> /tasks/2
   • tasks loader does not re-run
   • tasks/:id loader runs for id=2

A couple quick options off the top of my head:

• navigation aborts useDataRefresh, and the user may see semi-stale tasks data on the new route
• navigation aborts useDataRefresh and forces all loaders to run for that navigation
• navigation doesn't abort useDataRefresh and we do some logic around determining which routes from useDataRefresh are still active when it completes and merge their responses into loaderData (could cause a mid-view flicker?)

I think I might like option 2?

[ryanflorence]

I like • also.

Oh sorry, I like • at index 1 also.

Why do you hate <ol> in your comments Matt?

[brophdawg11]

l<ol> 😂

[janhesters]

Would polling look something like this:

import { useState, useEffect, useRef } from "react";
import { useDataRefresh } from "remix";

import { LikeSymbol } from "./like-symbol";

function LikeButton() {
  let { refresh, state } = useDataRefresh();

  useInterval(refresh, 5_000);

  return (
    <button>
      <LikeSymbol count={state.count} />
    </button>
  );
}

function useInterval(callback, delay) {
  const savedCallback = useRef();

  useEffect(() => {
    savedCallback.current = callback;
  }, [callback]);

  useEffect(() => {
    function tick() {
      savedCallback.current();
    }

    if (delay !== null) {
      let id = setInterval(tick, delay);
      return () => clearInterval(id);
    }
  }, [delay]);
}

?

[sapter]

I'm looking into switching to Remix from NextJS+ReactQuery. I have just such a use case and ReactQuery does refetch on focus by default. I like Ken's idea of a useDataRefresh hook combined with useBroadcastChannel. Have you given this some more thought? Any chance something like this will be added?

[sergiodxa]

This is already available as useRevalidate in RRv6.4.0 and son will be here in Remix too

[brophdawg11]

For reference - https://beta.reactrouter.com/en/v6.4.0-pre.2/hooks/use-revalidator

[m5r]

I'm making a PWA that serves data from the service worker's cache and then update the cache. When the cache is updated, I use a BroadcastChannel to let the app know it needs to revalidate the loader data.
Right now I'm POSTing to a noop action to trigger a revalidation but the useRevalidator() hook is exactly what I need.

Will the revalidator send a special header to let the loader know this is a data revalidation request? For my use case this would be very helpful so that I could make the service worker immediately respond with the updated response it cached after it had served the initial request.

Right now it revalidates every loader on the page and I don't know if I would prefer to revalidate only some specific loaders or every loader on the page.

Anyway, that's what the flow looks like if it's supposed to revalidate only one loader:

[brophdawg11]

I'm curious if you could achieve this behavior with a short lived cache TTL? Since the fresh data response above will effectively immediately trigger the revalidation calls - if you had even a couple second cache on that response I think your revalidation calls would use the cached value? I could be missing something about the service worker's interaction with the browser cache though.

[m5r]

Network request => Service worker fetch => Browser cache <=> Server

The service worker does hit the browser cache between reaching the server but it's up to the service worker to decide whether to return a response from its own cache or to fetch() and potentially hit the browser cache.
The SW doesn't know if the response it stored came from the browser cache or from the origin. I came up with the idea of the X-Remix-Revalidate header to have an exit condition and have the SW revalidate the loader data only once but there might be an alternative I don't see right now

[brophdawg11]

ok thanks for clarifying - that decision in the service worker is what I was missing. These types of "remix-specific" aspects of useRevalidator will get some deeper thought when we shift remix to consume the new [email protected] package once it stabilizes

[alextes]

I'm trying to switch to Remix from NextJS but we may be unable to without this piece. I quite like like Remix so would be happy to juggle a workaround in the interim but after searching quite extensively I can't find any vetted ones. I thought here would be the place to figure out if there is one, but lmk if you'd prefer a separate discussion.

Let me quickly describe our site, the use-case may also help inform the design. Our site has a few pages but its main page is a dashboard. This dashboard hosts various widgets, some interactive, although none cause navigation, or even submission of anything. It's just retrieving data in various ways. The data updates constantly. The most volatile data changes every 2s or so. If you'd like to see the site: https://ultrasound.money/

Approaches I've considered:

• Bundle all dashboard data in a single request and reload it on the smallest interval. Infeasible for us as some parts of the site fetch a lot of data infrequently.
• Same as the previous, but now in the loader figure out whether something has changed, and send only the changed data. On the client side, skip updates where data came in undefined.
• Use remix to load the data initially, but then on the client switch over to using swr. Exploring this one currently!

This part worked perfectly with Next's swr hook which currently refetches on an interval and propagates the new data from wherever it got called.

Reading the proposal, this would be a step in the right direction, but still wouldn't suffice. It has the refresh, but still lacks a way to selectively refresh pieces of data at different intervals.

Curious to hear what you think, and if this is even a type of site Remix expects to handle well.

Thanks for a great lib! 💛

[alextes]

I've thought about this more, read up on how Next suggests handling this and I've come to find that:

• you should probably just use swr in this scenario. Data that doesn't change often you can maybe only load when actions fire, and use loader's for.
• data that changes all the time, use swr, that is, client-side rendering. Don't ask Remix to render pages that will outdated seconds later.
• if you really want both, write an swr hook and a loader. Have the component use the swr when it can, and loader when it can't (which should be on server render or first-load). Haven't tried this, might not be great for perf.

[vdjurdjevic]

I could use both loader and SWR, but I have to maintain two different things that should do the same thing. I am not sure if I can call loader with API route from SWR, but If I can't then I have two different API results (API returns data in one format, loader takes that and rearranges the response a little bit for example), that does not sound like fun :D

[vdjurdjevic]

Also exploring the option to switch from NextJS + React Query to Remix. Same use case, a dashboard that polls data on a regular interval (45 sec), and receives events with WebSocket, and events also trigger data update.

[alextes]

Although using swr directly didn't work out for me. I believe I got errors about server code being in the client bundle, I realized, an approach just like it could work just fine.

[barbinbrad]

On the other side of the coin, is there any API to not refetch a particular route after an action? We have some pretty expensive queries at the root level, for example, that aren't likely to change on most actions.

[kiliman]

unstable_shouldReload

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

[wh1337]

Apologies to bump an old thread, but is there any update on this? This is crucial for us as we get messages from WebSockets and need to refresh.

If it's been released already, I probably missed it lol

[sergiodxa]

This has been added to RR as useRevalidator and now that Remix is about the finish the internal change to use RR v6.5 (next release should include it) it’s going to be available in Remix too

[sergiodxa]

Now that Remix is on the latest React Router it has access to useRevalidator which solves this proposal.

[brophdawg11]

Good call - I'll lock this proposal