Limits of Remix shouldRevalidate when skipping a loader's re-fetch after actions

Revalidation Scope and Opt-Outs

By default, Remix re-runs the loader for every active route on the page after an action completes. This ensures the UI remains synchronized with the server state. Because nested loaders are executed in parallel, the total time to resolve the revalidation batch is determined by the slowest loader in the hierarchy.

You can opt out of this behavior on a per-route basis using the shouldRevalidate export. Returning false from this function tells Remix to skip that specific route's loader for the current revalidation trigger, allowing the rest of the active routes to refresh normally.

Reliable Signals for Skipping

The shouldRevalidate function provides context that can be used to determine if a skip is safe. The reliability of these signals depends on the nature of your data:

• Params and URLs: Comparing currentParams and nextParams is a highly reliable signal. If the route parameters have not changed and the action did not target a resource linked to those parameters, the data is likely still valid.
• Action Result: The actionResult (or actionData) can be used to inspect what actually changed. If the action returns a specific flag or status indicating that the "expensive" data was not touched, skipping is safer.

Assumption: This assumes a standard Remix SSR setup. If you are using custom data routers or specific React Router adapters, the argument signatures for shouldRevalidate may vary slightly.

Stale UI Risks and Bounds

Skipping a loader introduces the risk of stale UI, particularly when data can be modified by external sources (e.g., background jobs, other users, or scheduled tasks) that the client-side action cannot track.

To bound these risks, consider these strategies:

• Navigation Triggers: A loader skipped after an action will still run during the next full navigation to a different route.
• Manual Revalidation: Use useRevalidator().revalidate() to force a refresh of all loaders when a specific client-side event occurs.
• Optimistic UI: Use useNavigation to update the UI immediately, reducing the perceived need for an immediate server-side re-fetch of the expensive loader.

Verification Steps

To verify your implementation, use these scoped checks:

1. Add a console.log inside both the shouldRevalidate function and the loader to confirm the skip logic triggers as expected.
2. Monitor the Network Tab in browser dev tools after an action; the skipped route should not appear in the batch of loader requests.
3. Manually change the database value for the expensive query and trigger an action; confirm the UI remains stale until the next navigation or manual revalidation.

Diagnostic Note: Are you using a shared cache (like Redis) for the expensive loader? If so, the performance bottleneck may be the network round-trip rather than the query execution itself.