Loader Cleanup Function for Stateful Data

[pspeter3]

Some frameworks like Convex, Firebase, or Supabase have stateful subscriptions for data loading. It would be great if you could subscribe to an object / topic in the loader and the listen to it in the component. The framework would need to provide hooks to separate subscription and reactivity but this would otherwise work today. The issue is that there is not a clear way to clean up the subscription when the route no longer matches. A cleanup function would allow the app to unsubscribe from the query.

[timdorr]

This wouldn't work for a server render. You can transfer a non-serializable object from the loader function to your component, primarily for this reason. A loader is meant to provide a snapshot of data, not an active connection or more complex object. This is obviously to serve the upstream Remix library, but works the same for anyone doing server rendering.

[pspeter3]

I agree this wouldn't work on the server but would still be great for the client in SPA applications.

[brophdawg11]

The issue is that there is not a clear way to clean up the subscription when the route no longer matches

Why couldn't you use a useEffect cleanup function in your route component? Combined with the new route.lazy feature you could then also use the module scope to store your stateful stuff in a route-specific manner.

// route.jsx
let statefulSubscriptionThing;

export async function loader() {
  if (!statefulSubcriptionThing) {
    statefulSubcriptionThing = createStatefulThing();
  }
  let data = await statefulSubscriptionThing.getData();
  return { data );
}

export function Component() {
  let data = useLoaderData();
  
  React.useEffect(() => () => {
    if (statefulSubcriptionThing) {
      statefulSubcriptionThing.destroy();
    }
  }, []);
  
  return <div>{data}</div>
}

[brophdawg11]

How so? With modern bundlers the module should be reused across different component instances and thus only a single module-level scope created. If you don't trust the module scope, then you could always put it on window.statefulSubscriptionThing.

[phikes]

This violates how the React team thinks about useEffect (refer to the documentation). Specifically:

but requires components to be resilient to effects being mounted and destroyed multiple times. Most effects will work without any changes, but some effects do not properly clean up subscriptions in the destroy callback, or implicitly assume they are only mounted or destroyed once.

In strict mode this becomes apparent: The loader is executed once, react executes the cleanup function and the component re-renders and now we destroyed our subscription and can't access the data anymore.

[phikes]

Building on top of this however you can use useRevalidator in your useEffect to handle multiple renders. In my example I use relay, but this applies to anything really.

  useEffect(() => {
    if (_data.isDisposed) revalidate(); // If the data was cleaned up, but we are re-rendering. You can check for your subscription here or whatever state you have to check if it was disposed/destroyed/...

    return () => _data.dispose(); // dispose upon cleanup
  }, []);

[TomasChmelik]

Any news on this? Using custom useEffect hook sound like a temporary workaround. Since react-router's loaders aim to replace loading useEffects I'd expect disposal support for returned value. Either with additional function like loaderCleanup or as special value returned from the loader (similar to defer).

[ethanwu10]

The useRevalidator technique doesn't work reliably - if the effect is ever triggered and needs to revalidate, that is because the data as used in the render that fired the effect is disposed, which also means that this render is passing a disposed handle to whatever is consuming it (i.e. usePreloadedQuery in Relay). Thus, the effect does nothing to prevent at least one render from using an already-destroyed loader data. This can be seen under strict mode.

[ChristophP]

I also wish there was a way to do cleanup. I'm using RTK Query and when I fetch data in a loader a subscription is added that needs to be unsubscribed when the user navigates away.

Too bad there seem to be no support for this yet.

[ChristophP]

Proposal for adding a way to add cleanup logic

Add a property to the argument for the loader which allows cleanup.
It would run whenever the page is unloaded, in other words as the user navigates away.
I called it onUnload to be consistent with the loader naming but there might be a better naming

Example code

const loaderFunc = async ({ request, params, onUnload }) => {
  // fetch and add a subscription
  const removeStateFullStuffCallback = await doSomeStateFullStuff();

  // add cleanup function which is called when navigating away
  onUnload(() => { removeStateFullStuffCallback(); });

  // return some data
  return {};
}

A concrete example for RTK Query

RTK Query adds subscriptions for data. Data is held in the cache until all subscriptions for it are removed. If for example only one page needs certain data it should be cleaned up when the page is left.

const loaderFunc = async ({ request, params, onUnload }) => {
  // fetch and add a subscription
  const queryResult = dispatch(api.endpoints.getFancyStuff.initiate(undefined, { forceRefetch: true }));

  // remove subscription when navigating away
  onUnload(() => { queryResult.unsubscribe(); });

 // await the query to delay the navigation till data is loaded 
 await queryResult;

  // return no data since components can access data via useQueryState()
  return null;
}

Open questions

• Does onUnload need to be async and awaited before the navigation happens? (not necessary for the RTK use case but might be worth considering)
• Is this the best API design? (I used a prop in the loader argument instead of an unloader prop on the route because often in order to unsubscribe you need variables from the scope of the loader, another popular API design for unsubscribing is to return a cleanup function, however since the return value of loader is already used for the loader data this wasn't easy to do without a breaking API change)
• can onUnload() be called more than once? If so, does it add several unloaders or replace the existing one?
• What about server renders? (one easy way to do this would be to have onUnload not do anything in this case)

Current workaround

Since this is not possible yet the current workaround is to use router.subcribe().

const loaderFunc = async () => {
  // fetch and add a subscription
  const queryResult = dispatch(api.endpoints.getFancyStuff.initiate({ forceRefetch: true }));

  // listen to next route change to remove the subscription when navigating away
  // first we will get the current route change, so we use a boolean to fire the callback on the second invocation
  let isUnload = false;
  const unsubscribeFromRouter = router.subscribe(() => {
    if (isUnload) {
      console.log("UNLOAD");
      queryResult.unsubscribe(); // remove RTK Query subscription
      unsubscribeFromRouter(); // stop listening to route changes
    }
    isUnload = true;
  });

   // await the query to delay the navigation till data is loaded 
   await queryResult;

  // return no data since components can access data via useQueryState()
  return null;
}

However, this is not great since it

1. involves some boiler plate and
2. makes use of router.subscribe() which is not officially documented and marked as internal

Other workarounds

Using useEffect inside a compont but

• it kind of defeats the whole purpose of having loaders run outside of the render cicle and introduces waterfall dependencies again
• it's possible for useEffect not to run again even if navigation happened if two pages use the same component. useEffect react to render (which might not happen if the component is already there), loader react to navigation which is closer to what one wants

[FlorentHoareau]

Thanks @ChristophP for the idea of using router.subscribe(). Despite being marked as internal, I think it's the most logical way of caching the route change events (useEffect is indeed too hackish).

There are still some issues in your proposal:

• The extra boilerplate needed in each loader function
• The weird isUnload boolean, which relies on the fact that the subscription event will be called twice. It also unloads too early: if I have a child route active, I do not want the cleanup function from the outermost loader to be called because the component needing it is still rendering.

I figured out a way to address both of these, and act almost as if React Router had a proper unloader feature.
It uses the state.matches object to monitor which routes become inactive and calls the cleanup function at that moment.

reactRouterUnloaders.ts

import type { createBrowserRouter } from "react-router-dom";

type Router = ReturnType<typeof createBrowserRouter>;

// eslint-disable-next-line @typescript-eslint/no-explicit-any
type LoaderData = any;
type UnloaderFn = (data: LoaderData) => void;

const UnloaderMap = Map<string, [UnloaderFn, LoaderData]>;

/** Adds a call to route unloaders when their loaded data is no longer needed. */
export const addUnloaderSupportToRouter = (router: Router) => {
  let routesWithUnloader = new UnloaderMap();
  router.subscribe((state) => {
    // Remember all matching routes that declare an unloader function.
    const newRoutesWithUnloader = new UnloaderMap();
    state.matches.forEach((match) => {
      // @ts-expect-error "unloader" does not exist on exported Route type from react-router-dom
      const unloader = match.route.unloader as UnloaderFn | undefined;
      if (unloader !== undefined) {
        newRoutesWithUnloader.set(match.route.id, [
          unloader,
          state.loaderData[match.route.id],
        ]);
      }
    });

    // Call unloaders of routes that no longer match.
    routesWithUnloader.forEach(([unloader, loaderData], key) => {
      if (!newRoutesWithUnloader.has(key)) {
        unloader(loaderData);
      }
    });

    routesWithUnloader = newRoutesWithUnloader;
  });
};

Use case

Sample loader/unloader functions

import { makeLoader, useLoaderData } from "react-router-typesafe";

export const loadMyData = makeLoader(({ params }) => {
  const myData = ... // load your data here
  return myData;
});

export const unloadMyData = (
  myData: ReturnType<typeof loadMyData>,
) => {
  myData.dispose(); // cleanup here
};

export const MyPageComponent = () => {
  const myData = useLoaderData<typeof loadMyData>();
}

In your routes

export const routes = [
...
{
 path: "path/to/my/page",
 loader: loadMyData,
 unloader: unloadMyData, // This is the new key
 element: <MyPageComponent />,
 children: [
    // nested routes
  ] 
},
...
];

Where you create your router

import { addUnloaderSupportToRouter } from "./utils/reactRouterUnloaders";
import { routes } from "./routes";

const router = createBrowserRouter(routes);
addUnloaderSupportToRouter(router);

NB: I used makeLoader from react-router-typesafe here to get types at useLoaderData but you are not forced to.
NB2: it is important to use ReturnType<typeof loadMyData> to type the cleanup function as there is no check anywhere and it could easily become wrong.

[ChristophP]

Hi there,
since this topic still seems to be somewhat unsolved, I wanted to share my recent progress for a solution.
react-router 6.23 came out with a new data strategy API which I used to implement something that I think solved the problem of unsubscribing.
Feedback welcome: #11527