Feedback wanted: React query or RTK Query with loaders using the new data strategy

[ChristophP]

Subscription management with loaders

Data loading and caching libraries such as RTK Query use a subscription based model to determine how long entries in the cache have to be kept around.

This typically works with hooks and a lot of discussions out there suggest using a component, but I felt that the whole point of the data APIs (since react router 6.4) is to get data loading matters out of the components tree.
Getting the loading for libs like RTK Query and react query out of the component tree properly thus far has been tough to do with react-router. Do do this with RTK Query one would have to subscribe to "start listening for data" and unsubscribe to "stop listening" when data is no longer needed.
React router offered no way to my knowledge to figure out when "a route no longer matches".

The following is my attempt to provide an API for this, using the the unstable_dataStrategy API shipped in react-router version 6.23.

Feedback welcome

Since I am looking to use this I would love to hear some opinions about how well you thin this would work.
Do you see any problems with it?
Do you have the same need to manage subscriptions for a data loading lib that was previously hard to achieve?
Is this solution in line with intented usage of the data strategy API?
Do you see an easier way to do this?

General idea

1. Determine when routes no longer match: Use the data strategy function to get access to matches. Keep around the previous matches to diff when a route that matched before no longer does.
2. Pass a function to the loaders which allows registering unload handlers: The data strategy API allows for passing extra argument to the loaders, so we use it to pass a onUnload(handler) function to the loader. It takes a function as an argument and when called that argument function will be registered to run when the route no longer matches.

Implementation

// data-strategy.ts
import type {
  unstable_DataStrategyMatch as DataStrategyMatch,
  unstable_DataStrategyFunction as DataStrategyFunction,
} from "react-router-dom";

type OnUnloadArg = () => void;
export type HandlerCtx = { onUnload: (fn: OnUnloadArg) => void };

export function createDataStrategy() {
  const unloaderEventTarget = new EventTarget();
  let previousMatches: string[] = [];

  // fire unload event for each unloading route
  const dispatchUnloadEvents = (matches: DataStrategyMatch[]) => {
    previousMatches.forEach((id) => {
      const match = matches.find((m) => m.route.id === id);
      // Dispatch unload event IF
      // - if the entry is not matched anymore or shouldLoad is true
      // - if the entry is still matched but shouldLoad is true, because the new loader will add this again
      if (!match || match.shouldLoad) {
        unloaderEventTarget.dispatchEvent(new CustomEvent(`unload-${id}`));
      }
    });
    // store matches for next run
    previousMatches = matches.map((match) => match.route.id);
  };

  // add second param to loaders which is a callback which get's called when the route is not a match anymore
  const dataStrategy: DataStrategyFunction = ({ matches }) => {
    dispatchUnloadEvents(matches);

    // Run loaders in parallel with the `context` value
    return Promise.all(
      matches.map((match) =>
        match.resolve(async (handler) => {
          // add unload handler and pass it to loader as argument
          const onUnload = (fn: () => void) => {
            unloaderEventTarget.addEventListener(`unload-${match.route.id}`, fn, { once: true });
          };
          // Whatever you pass to `handler` will be passed as the 2nd parameter
          // to your loader/action
          const result = await handler({ onUnload });
          return { type: "data", result };
        }),
      ),
    );
  };

  return { dataStrategy, dispatchUnloadEvents };
}

Usage

// router.ts
import { createBrowserRouter } from "react-router-dom";
import type { LoaderFunction } from "react-router-dom";

import { createDataStrategy, type HandlerCtx } from "./data-strategy";

const { dataStrategy, dispatchUnloadEvents } = createDataStrategy();

const router = createBrowserRouter(
  [
    {
          Component: AppLayout,
          loader: (_loaderArgs, handlerCtx) => {
            console.log("Intermediate loader sequence");
            const { onUnload } = handlerCtx as HandlerCtx;
            // add a subscription
            const timerId = setInterval(() => console.log("Subscribed", new Date()), 1000);
            // register unsubscribe function
            onUnload(() => {
              clearInterval(timerId);
              console.log("unloading here");
            });
            return null;
          }, 
     }
  ],
  { unstable_dataStrategy: dataStrategy }, // register data strategy here
);

// handle hot reloading
if (module.hot) {
  module.hot.dispose(() => {
    // dispatch events for all registered event handlers to make sure hot reloading doesn't keep any lingering subscriptions 
    // we pass an empty matches array so that all routes are "unloaded"
    dispatchUnloadEvents([]); 
    router.dispose();
  });
}

Loader Example for RTK Query

{
          Component: AppLayout,
          async loader: (_loaderArgs, handlerCtx) => {
            console.log("Intermediate loader sequence");
            const { onUnload } = handlerCtx as HandlerCtx;
            // add a RTK Query subscription
            const promiseResult = dispatch(api.endpoints.someEndpoint.initiate());
            // register unsubscribe function to be called when route doesn't match anymore
            onUnload(promiseResult.unsubscribe);
            const { status, data, error, refetch } = await promiseResult; 
            return data;
          }, 
     }

Related issues and discussions

• Loader Cleanup Function for Stateful Data #10200 (reply in thread)
• React Router 6 Loaders with RTK Query reduxjs/redux-toolkit#2751
• https://medium.com/@bitsol/using-react-tool-kit-rtk-query-with-react-router-v6-9eac07521bc5 (good example but offers no solution how to unsubscribe)

[FlorentHoareau]

Good to see that React Router is willing to provide a way to completely customize data fetching.
I think that the fact they are not providing any built-in event to catch unmatched routes in unstable_dataStrategy is actually a good thing, since it's intended to be a low-level api.

Maybe we can propose a few "standard" strategies, like the one you propose with the unloaders, or some single-fetch strategy (which seems to be the real reason why they're introducing this feature), but since it's still an unstable feature, I think it is reasonable to keep it as it is.

The only small hack that I do not like is the hot reload thing, but that is such an edge case that I do not have any better idea about how to solve it. I'd prefer having this handled directly by the library instead of relying on each developer, especially because it's a debug-time-only issue.

[ChristophP]

@FlorentHoareau thanks for the feedback.

I think that the fact they are not providing any built-in event to catch unmatched routes in unstable_dataStrategy is actually a good thing, since it's intended to be a low-level api.

yeah I like the API. It really gives a lot of flexibility to the users.

Maybe we can propose a few "standard" strategies, like the one you propose with the unloaders

yeah, hopefully in the future things like this will come out of the box. But until then, I think this will help managing subscriptions for things like RTK Query. So I will start using this until I find something better.

[tannerhallman]

Curious if anything has changed with React Router 7?

[ChristophP]

I didn't see any big changes in this regard other than the fact that dataStrategy is now stable

[hornta]

It doesn't seem to unsubscribe to queries when user navigates to a route that doesn't have a loader function. react-router doesn't execute the dataStrategy function so there is no way to stop subscribing to the data. Do you know of a way to unsubscribe when user leaves route? I haven't been able to find such an API to do this for. In the meantime, I've put a dummy loader function on each route that doesn't have a loader function.

[ChristophP]

Ah good to know. I never had this case.
I usually wrap all routes with a route that has a loader and that works for me. That way I think you don't have to put a loader on each route but one on the root route is enough.

[hornta]

Having loader only on the root route doesn't work. I still have to put a loader on each child route. I've solved it like this for now:

export function ensureRoutesHaveLoaderFunction(routeObjects: RouteObject[]) {
	for (const routeObject of routeObjects) {
		if (routeObject.loader === undefined) {
			routeObject.loader = () => ({});
		}
		ensureRoutesHaveLoaderFunction(routeObject.children ?? []);
	}
}

const routeObjects: RouteObject[] = [
	{
		path: "*",
		element: <PageNotFound />,
	},
        ...
]

ensureRoutesHaveLoaderFunction(routeObjects);

export const router = createBrowserRouter(routeObjects, {
	dataStrategy
});

[ChristophP]

Ah ok, well it's a workaround. But it would be nice if react router offered an API for this.

[ChristophP]

FYI @tannerhallman @hornta

I noticed since unstable_dataStrategy became dataStrategy (around 6.28.0) the signature for the return value changed slightly.
Instead of a result one now needs to return an object of results, so I am posting the latest version again.

import type {
  DataStrategyMatch,
  DataStrategyFunction,
  DataStrategyResult,
} from "react-router-dom";

type OnUnloadArg = () => void;
export type HandlerCtx = { onUnload: (fn: OnUnloadArg) => void };

export function createDataStrategy() {
  const unloaderEventTarget = new EventTarget();
  let previousMatches: string[] = [];

  // fire unload event for each unloading route
  const dispatchUnloadEvents = (matches: DataStrategyMatch[]) => {
    previousMatches.forEach((id) => {
      const match = matches.find((m) => m.route.id === id);
      // Dispatch unload event IF
      // - if the entry is not matched anymore
      // - if the entry is still matched but shouldLoad is true, because the new loader will add this again
      if (!match || match.shouldLoad) {
        unloaderEventTarget.dispatchEvent(new CustomEvent(`unload-${id}`));
      }
    });
    // store matches for next run
    previousMatches = matches.map((match) => match.route.id);
  };

  // add second param to loaders which is a callback which get's called when the route is not a match anymore
  const dataStrategy: DataStrategyFunction = async ({ matches }) => {
    dispatchUnloadEvents(matches);

    // Run loaders in parallel with the `context` value
    const matchesToLoad = matches.filter((m) => m.shouldLoad);
    const results: DataStrategyResult[] = await Promise.all(
      matchesToLoad.map((match: DataStrategyMatch) =>
        match.resolve(async (handler) => {
          // add unload handler and pass it to loader as argument
          const onUnload = (fn: () => void) => {
            unloaderEventTarget.addEventListener(
              `unload-${match.route.id}`,
              fn,
              { once: true },
            );
          };
          // Whatever you pass to `handler` will be passed as the 2nd parameter
          // to your loader/action
          return handler({ onUnload });
        }),
      ),
    );
    const dataStrategyResults: Array<[string, DataStrategyResult]> =
      results.map((result, i) => [matchesToLoad[i]?.route.id ?? "", result]);
    return Object.fromEntries(dataStrategyResults);
  };

  return { dataStrategy, dispatchUnloadEvents };
}

[tannerhallman]

Thank you for following up

[einarq]

A bit late here…
I’m using RTKQ in data loaders, but I’m simply using it to prime the cache. So I can immediate unsubscribe from updates, and rely on the hooks in the components where I want to use the data.

I probably don’t have the full context but this seems a bit overly complex to me.

[ChristophP]

Yeah, hooks work well for some things but what you don't get with hooks is

• not rendering until the data is there
• in legacy code bases with class components you can't use them (you have to subscribe and unsubscribe manually in each component that uses the data)
• fetching as the result of a route change rather than as the result of a render (react router loaders let you fetch before you render).

I probably don’t have the full context but this seems a bit overly complex to me.

I agree that the whole thing looks more complex than it needs to be. I think most of the complexity is due to the fact that we have to implement our own data strategy that supports unsubscribing. It's nice to have this API as a stop gap but @ryanflorence Ideally react router will support unsubscribing in loaders one day and we don't have to write this logic ourselves.

[einarq]

If you don’t want to render until the data is ready you can await the RTKQ initiate call in the loader.
Then use the hook to get the data closer to where you use it.
When it comes to classes it’s quite easy to create a smal render prop component that only reads the data and passes it down to the child.

[einarq]

You shouldn’t need a lifecycle in the loader to unsubscribe, you do that immediately.

[IAluI]

@ChristophP How will Automated Re-fetching work in this case? What I mean is that if we move RTK queries to the loader, then redux must somehow be able to call the loader (probably via react-router action).