Prevent Unnecessary Dispatches in useQuery with skipToken

[yeefun]

When using useQuery, can we avoid dispatch calls here by passing in skipToken? The current implementation causes performance issues when multiple components call useQuery simultaneously, resulting in too many dispatches. This forces me to use useLazyQuery to control trigger timing. However, if skipToken could prevent these dispatch calls, I wouldn't need this workaround.

[markerikson]

useQuery does actually use dispatch internally to retrieve some info on subscription status, separate from actually dispatching actions.

However, that perf chart seems abnormally complicated. Can you show your store setup? How many middleware are being added to the store? Any chance you could zip up and attach the JSON perf profile data?

[yeefun]

However, that perf chart seems abnormally complicated. Can you show your store setup? How many middleware are being added to the store? Any chance you could zip up and attach the JSON perf profile data?

21 middleware. 90 more slices.

Trace-20250629T134849.json

Btw, repeatedly calling dispatch in a short period of time has been a significant performance drain for my project, forcing me to move slices that require these operations to Zustand.

[yeefun]

Currently, I'm forced to use lower-level APIs such as useLazyQuerySubscription and useQueryState to work around performance issues, which is quite frustrating for me.

import { skipToken } from '@reduxjs/toolkit/query';
import { useEffect } from 'react';

import { xxxApi } from 'apis/xxxApi';
import { useShallowStableValue } from 'hooks/useShallowStableValue';

type Param =
  | typeof skipToken
  | {
      objectId: string;
      objectType: string;
      referenceId: string;
      referenceType: string;
    };

const thirtySecondsInMs = 30 * 1000;

/**
 * Using useLazyGetMentionedObjectTitleQuery here prevents unnecessary dispatches
 * that would occur with useGetMentionedObjectTitleQuery (even with skipToken, see: https://github.com/reduxjs/redux-toolkit/blob/af3e75bb9e6a51e13603d2a5684ef3ba1da07e3b/packages/toolkit/src/query/react/buildHooks.ts#L1628).
 * This avoids performance hits when this hook is called in multiple places at once.
 */
export function useGetMentionedObjectTitleIfNeeded(param: Param) {
  const stableParam = useShallowStableValue(param);

  const [getMentionedObjectTitle] =
    xxxApi.endpoints.getMentionedObjectTitle.useLazyQuerySubscription();

  const { data, fulfilledTimeStamp, isFetching } =
    xxxApi.endpoints.getMentionedObjectTitle.useQueryState(
      stableParam,
      {
        selectFromResult: ({ data, fulfilledTimeStamp, isFetching }) => ({
          data,
          fulfilledTimeStamp,
          isFetching,
        }),
      }
    );

  useEffect(() => {
    if (stableParam === skipToken) {
      return;
    }

    const isStale = fulfilledTimeStamp
      ? Date.now() - fulfilledTimeStamp > thirtySecondsInMs
      : true;

    if (!isStale || isFetching) {
      return;
    }

    const { objectId, objectType, referenceId, referenceType } = stableParam;

    getMentionedObjectTitle({
      objectId,
      objectType,
      referenceId,
      referenceType,
    }).unwrap();
  }, [getMentionedObjectTitle, fulfilledTimeStamp, stableParam, isFetching]);

  return data;
}

[phryneas]

What are those 21 middleware? Usually I wouldn't expect more than 3 to 5. That might have a significant impact.

[yeefun]

What are those 21 middleware? Usually I wouldn't expect more than 3 to 5. That might have a significant impact.

I see. Could you explain why there's a significant performance difference when middleware increases from 5 to 21? These middleware are designed to respond to specific actions for operations such as persistence, data schema validation, and syncing data. Many of them use the listener middleware you provide. I'm not certain what would be appropriate besides middleware. If having too many middleware is indeed problematic, what alternatives would you suggest?

[markerikson]

@yeefun : yeah, to echo Lenz, having 21 middleware added to your store is not good for perf.

Middleware form a function call pipeline that wraps dispatch. If I have 3 middleware, then store.dispatch(action) actually does:

• mid1(action)
  • mid2(action)
    • mid3(action)
      • store.dispatch(action)
        • rootReducer(state, action)
      • return dispatch
    • return mid3
  • return mid2
• return mid1

To put it another way: if you have N middleware, that's N extra function calls for every call to dispatch. So, if you have 21 middleware, that's 21 extra function calls every time there's a dispatch.

Typically we would expect that a Redux store would have 3-4, usually thunk, an RTK Query API middleware, and maybe the listener middleware.

These middleware are designed to respond to specific actions for operations such as persistence, data schema validation, and syncing data. Many of them use the listener middleware you provide.

This part confuses me. Are you calling createListenerMiddleware() many times? You should only need create one single listener middleware instance, add it to the store, and then add many listeners to that single middleware.

Can you show the actual store setup code, and possibly also some examples of these middleware? That would help me understand what the app itself needs to do.

[markerikson]

Also, something about that perf trace JSON file seems possibly corrupted or cut off - Chrome DevTools doesn't want to load it properly. I may have gotten it to load in the Firefox Profiler viewer, I think?

[yeefun]

Can you show the actual store setup code, and possibly also some examples of these middleware? That would help me understand what the app itself needs to do.

reduxStore.ts

middleware: (getDefaultMiddleware) => {
  /**
   * Some IMPORTANT notes before you modify the middleware:
   *
   * - The order of middleware is important. Don't arrange it randomly, as this can cause serious problems. If a specific middleware needs to be in a certain order, add a comment starting with "ORDER MATTERS:" to explain why.
   *   The `decomposePersistedActionMiddleware` is a crucial middleware that influences the order of other middleware. Please read its comment carefully.
   *
   * - If you're using middleware created with `createListenerMiddleware`, it's better to put it before the serializability check middleware. This is because the listener middleware can handle actions that contain functions, which the serializability check does not allow. The serializability check middleware is part of the default middleware.
   *
   * - For all middleware that comes before the default middleware, make sure to return the result of `next(action)`. This is important because the default middleware includes Redux Thunk, which needs its return value to be sent back using `return next(action)`.
   *
   * - Avoid using conditions to decide when to apply middleware. For example, don't use code like this: `...(isMobileApp ? [mobileLocalSyncMiddleware] : [])`. This can cause problems with type safety. Instead, put the condition inside the middleware and add a comment like "Mobile only" here.
   *   To solve this issue, Redux Toolkit uses something called a "Tuple," which is returned by `getDefaultMiddleware`, to create middleware. This helps prevent issues that can occur when TypeScript tries to determine the types of combined arrays using the spread operator.
   *
   * - The earlier the listener middleware is placed, the later it is executed.
   */
  const middlewares = getDefaultMiddleware({
    serializableCheck: false,

    // If enabling this middleware, testing performance and syncing might become so slow that it can't help us reflect the issue our users face.
    immutableCheck:
      import.meta.env.DEV &&
      import.meta.env.VITE_SHOULD_ENABLE_IMMUTABLE_CHECK === 'true'
        ? {
            ignoredPaths: [
              /**
               * Dispatching update to `zoom` and `offset` causes too many re-selects, which degrades performance. So we move them to zustand and directly mutate the state in Redux store for persistence.
               */
              /^tabList\.byId\.whiteboards\.[0-9a-f-]+\.zoom$/,
              /^tabList\.byId\.whiteboards\.[0-9a-f-]+\.offset$/,
              /^tabList\.byId\.whiteboards\.[0-9a-f-]+\.tool$/,
              /^tabList\.byId\.cards\.[0-9a-f-]+\.whiteboardLocationActiveInfo\.whiteboardState\.zoom$/,
              /^tabList\.byId\.cards\.[0-9a-f-]+\.whiteboardLocationActiveInfo\.whiteboardState\.offset$/,
            ],
          }
        : false,
  })
    .prepend(
      /**
       * ORDER MATTERS: We must validate the data schema first so that the following middlewares can receive the schema-validated data.
       */
      schemaValidationMiddleware,

      /**
       * Non-Web only
       *
       * ORDER MATTERS: The middleware must be placed before `decomposePersistedActionMiddleware`. This ensures it receives composite persisted actions, which are necessary for making transactions in the local database.
       */
      persistenceMiddleware,

      /**
       * ORDER MATTERS: The middleware must be placed before `decomposePersistedActionMiddleware`. This ensures it receives composite persisted actions, which are necessary for making transactions for cloud sync.
       */
      syncMiddleware,

      /**
       * Electron only
       *
       * ORDER MATTERS: The middleware must be placed before `decomposePersistedActionMiddleware`. It's more reasonable to sync composite persisted actions across Electron windows.
       */
      electronLocalSyncMiddleware,

      /**
       * Mobile only
       *
       * ORDER MATTERS: The middleware must be placed before `decomposePersistedActionMiddleware`. It's more reasonable to sync composite persisted actions across webviews and the main app (mobile package).
       */
      mobileLocalSyncMiddleware,

      /**
       * ORDER MATTERS: The middleware decomposes composite persisted actions into multiple basic persisted actions. This means that when a composite persisted action is dispatched, the middleware before and after this one will receive different actions.
       * When adding a new middleware, consider if it needs to handle composite persisted actions and place it accordingly.
       */
      decomposePersistedActionMiddleware,

      linkIndexMiddleware,

      /**
       * Electron only
       */
      searchIndexMiddleware,

      /**
       * Non-Mobile only
       */
      localSnapshotMiddleware,

      /**
       * Mobile only
       */
      addSourcesDataWhileSyncingWhiteboardObjectsMiddleware,

      todoIndexMiddleware,
      highlightElementTitleMiddleware
    )
    .concat(
      baseApi.middleware,

      /**
       * Non-Mobile only
       */
      redirectAndRemoveTabLocalStatesBeforeDeleteTabsMiddleware,

      /**
       * Non-Mobile only
       */
      syncTabSourceIdUpdateToRouteMiddleware,

      /**
       * Non-Mobile only
       */
      closeTabsDueToObjectsDataChangeMiddleware,

      /**
       * Non-Mobile only
       */
      removeQuickAccessStatusesDueToWhiteboardsDataChangeMiddleware,

      /**
       * Non-Mobile only
       */
      removeRelationsDueToCardsDataChangeMiddleware,

      /**
       * Non-Mobile only
       */
      removeReadAccount2ObjectDueToChatDataChangeMiddleware,

      /**
       * Non-Mobile only
       */
      removeActionItemDueToDataChangeMiddleware,

      avoidUnnecessaryActionsMiddleware
    );

  return middlewares;
},

schemaValidationMiddleware.ts

export const schemaValidationMiddleware: Middleware<{}, ReduxRootState> =
  (store) => (next) => (action) => {
    if (!isAction(action)) {
      return next(action);
    }

    // ...

    return next({
      ...action,
      payload:
        validBasicDataManipulationActions.length > 1
          ? validBasicDataManipulationActions
          : validBasicDataManipulationActions[0]!.payload,
    });
  };

localSnapshotMiddleware.ts

export const localSnapshotMiddleware =
  localSnapshotMiddlewareInstance.middleware;

const startReduxListening =
  localSnapshotMiddlewareInstance.startListening.withTypes<
    ReduxRootState,
    ReduxDispatchType
  >();

startReduxListening({
  matcher: (action) =>
    isAnyOf(
      updateXxxData,
      updateYyyData,
    )(action),

  effect: async (action, listenerApi) => {
    if (isMobileApp) {
      return;
    }

    // ...
  },
});

searchIndexMiddleware.ts

const searchIndexMiddlewareInstance = createListenerMiddleware();

export const searchIndexMiddleware = searchIndexMiddlewareInstance.middleware;

const startReduxListening =
  searchIndexMiddlewareInstance.startListening.withTypes<
    ReduxRootState,
    ReduxDispatchType
  >();

startReduxListening({
  matcher: (action) =>
    isAnyOf(
      addXxxData,
      addYyyData,
    )(action),

  effect: async (action, listenerApi) => {
    if (!isElectron) {
      return;
    }

    // ...
  },
});

startReduxListening({
  matcher: (action) =>
    isAnyOf(
      updateXxxData,
      updateYyyData,
    )(action),

  effect: async (action, listenerApi) => {
    if (!isElectron) {
      return;
    }

    // ...
  },
});

[yeefun]

Also, something about that perf trace JSON file seems possibly corrupted or cut off - Chrome DevTools doesn't want to load it properly. I may have gotten it to load in the Firefox Profiler viewer, I think?

Strange. I used Chrome Version 138.0.7204.50 (Official Build) (arm64) DevTools Performance tab to generate this profile. Let me try again: Trace-20250630T013424.json

[EskiMojo14]

why are you creating multiple listener middleware instances, instead of registering all of your listeners to one instance?

[markerikson]

@yeefun Gotcha, thanks.

I looked at the minified app bundle that was linked from the perf trace, and I think I see at least 10 different instances of the listener middleware being created. Is there a reason why that isn't one listener middleware instance instead?

(Per the perf profile issue: when I load it, I get an error that cannot read properties of undefined (reading 'frame_sequence'). I'm on Chromium 131 atm... maybe the format changed recently and 138 is generating a profile 131 can't read?)

[yeefun]

@EskiMojo14 @markerikson I wasn't aware that creating multiple listener middleware instances was inadvisable. I don't fully recall the specific reason for doing so—it was likely because this approach seemed more modular.

[markerikson]

@yeefun Another small thing I just noticed. This:

  matcher: (action) =>
    isAnyOf(
      updateXxxData,
      updateYyyData,
    )(action),

should be rewritten as:

  matcher: isAnyOf(
      updateXxxData,
      updateYyyData,
    )

Tiny thing, but the current code is creating a new isAnyOf matcher instance for every dispatched action, which isn't necessary. `

For that matter, I'd also suggest changing any of the conditional listeners / middleware to only add them in the environments where they actually matter. For example, there's no reason to add a listener that is going to check against every action, but immediately bail out if (!isElectron).

[yeefun]

Tiny thing, but the current code is creating a new isAnyOf matcher instance for every dispatched action, which isn't necessary. `

@markerikson Thanks for the suggestion! I did this because if I rewrite it into

matcher: isAnyOf(
    updateXxxData,
    updateYyyData,
  )

effect: (action) => {

The action parameter in the effect will be typed as UnknownAction. Do you know how to resolve this typing issue?

[yeefun]

For that matter, I'd also suggest changing any of the conditional listeners / middleware to only add them in the environments where they actually matter. For example, there's no reason to add a listener that is going to check against every action, but immediately bail out if (!isElectron).

@markerikson I found that following this approach creates a type issue, as mentioned in this comment:

Avoid using conditions to decide when to apply middleware. For example, don't use code like this: ...(isMobileApp ? [mobileLocalSyncMiddleware] : []). This can cause problems with type safety. Instead, put the condition inside the middleware and add a comment like "Mobile only" here.

How do you solve it?