Proposal: Add Opt-Out for Fetcher Persistence in Non-Standard Use Cases

[lifeiscontent]

Background

Before the introduction of v3_fetcherPersist, I was utilizing a key for a fetcher to determine which fetcher was actively running. My use case, however, deviates from the typical Remix request loop, which operates as follows:

1. The loader runs.
2. loaderData becomes accessible in the route component.
3. The action runs.
4. actionData or fetcher.data can be accessed within the route component.

The Use Case

In my scenario, there's a risk that our customers could exceed the limit of query parameters. To address this, we use a combination of loaderData and actionData, structured as:

export default function Route() {
   const loaderData = useLoaderData<typeof loader>();
   const fetcher = useFetcher<typeof action>();
   const data = fetcher.data ?? loaderData;
   
   return <>...</>;
}

Here, when the fetcher runs, its data takes precedence over loaderData, and we use FormData to update the current data.

The Problem

Previously, before v3_fetcherPersist existed, I could do something like:

const fetcher = useFetcher({ key: 'some-key' });

This allowed me to use the same fetcher in several sub-components that needed access to the specific fetcher matching the key. However, with the current implementation, I must first create a fetcher without the key and then pass that fetcher to all sub-components needing access. This approach makes the code much harder to write and maintain.

Additionally, the issue arises when a key is used in useFetcher. On the first render, this page can potentially cache and display stale data from the fetcher because it is persisted. This is particularly problematic in scenarios where data needs to be fresh and updated immediately.

Proposed Solution

It would be beneficial to allow developers to opt out of fetcher persistence for specific use cases. Although using URLSearchParams is the recommended approach, there are limitations due to the maximum length of a query string and the potential security concerns of submitting sensitive data via the URL.

I propose reintroducing the persist functionality from the original RFC, with the ability to pass persist: false to opt out of the fetcher’s persistence when needed.

[brophdawg11]

Would it be possible to create a minimal reproduction of the UX you're describing so we can be sure we fully understand the use-case? That way we can play around with it and see what the options are.

[lifeiscontent]

yep, I'll try to put something together tomorrow :)

[lifeiscontent]

@brophdawg11 here you go: https://github.com/lifeiscontent/fetcher-persist-proposal-example please check the readme for instructions and explanation of the problem

[lifeiscontent]

@brophdawg11 any updates here?

[lifeiscontent]

@brophdawg11 bump