Callsite Revalidation Opt-out

[ryanflorence]

tl;dr

<Form shouldRevalidate={(revalidateFuncArg) => false} />
fetcher.submit(data, { shouldRevalidate: () => true });

Background

After actions are called, for any reason, a revalidation is automatically initiated. You can opt-out of that revalidation with the route shouldRevalidate property. This works great for a lot of cases and is familiar to geriatric React developers like me who remember shouldComponentUpdate.

One way to think about our current “revalidation opt-out” is that it is part of a routes “definition”, or a “definition site opt-out”. It doesn’t matter what triggered the revalidation, the route’s definition gets to decide if it wants to participate in revalidation. This is good because the idea is that developers can look at what the loader uses in order to define the route’s shouldRevalidate. If it uses a certain search param, or url params, or loads data related to some special formData going to the action, all you have to know is the route’s own loader and not worry about the rest of the app.

However, sometimes these shouldRevalidate functions can be tricky write with that model, and developers (including myself) often over-optimize (causing stale data bugs) or under-optimize (making it pointless).

I’ve found in my own code that it’s often easier to answer the question “should this route revalidate?” at the “call site”: the place where a <Form> is rendered or a fetcher.submit() is called.

Use Case:

A very easy case to think about is a newsletter sign up form at the bottom of multiple pages. If three routes are matching on a page then three revalidation requests will go out when the user submits the form. But, being subscribed to the newsletter is irrelevant to every loader in the app.

To get Remix to avoid making all three revalidation fetches for the newsletter form, each route must define a shouldRevalidate. Typically it’s far easier to check if the formData is for the newsletter signup instead of what the loader needs. This is not the “definition site” model (what does this loader care about?) but is instead whack-a-mole for every route for every action that is irrelevant to loaders.

Open questions:

• GET revalidation (URLSearchParam changes), <Link> <Form> fetcher.load

[AndreSilva1993]

Are there any news on this one? I'm currently handling a sort of similar scenario where I'm using a fetcher.Form to dismiss notifications and would like to avoid having every loader revalidated - since the notifications are being fetched via a resource route periodically, there's no need at all to update any information present in the page.

Currently I'm thinking of just opting out entirely off the useFetcher API and just using a plain fetch plus useState to have optimistic UI - whereas I would much rather prefer the useFetcher / fetcher.formData combo since it works flawlessly, apart from the automatic revalidations.

[codeAdityagithub]

Is there any update? I also stumbled upon this when i was building a comment section. The replies for a comment are fetched when the user clicks to see them, and the replies are added to that component only. But when I use fetcher.submit to submit the reply, remix revalidates all the above comments also that user has fetched replies for. I am rather new to remix and i am not able to find a way to handle this.

[willhoney7]

This is our biggest pain point for Remix. In addition to callsite revalidation opt-out, we would greatly benefit from callsite revalidation opt-in. useRevalidator is great, but can I please just revalidate a single route? I think I'm going to end up creating a "revalidate data X" action (which will be a noop on the backend), and then create a global shouldRevalidate for every single other route in our app that knows to ignore that one. Woof!