did you find a workaround to this issue? i have the same issue and am debating not using the fetcher and just doing it myself.

I did not.

As much as I loved Remix overall, this was for a personal project that I just wanted to ship, and I decided Remix was too new for me to go all in on at the time.

The easiest way I found to deal with this was to use a fetcher reset data route.

routes/data/reset-fetcher.ts:

export const action = () => {
    return null;
}

That way you can just hit that route with any fetcher and it'll reset the data to null.

I use it inside a helper, so i've got a little function called resetFetcher that takes a fetcher as an argument and then makes a call to the reset route.

resetFetcher.ts:

export const resetFetcher = (fetcher) => {
  fetcher.submit({}, { action: "/data/reset-fetcher", method: "post" });
};

An example of this inside a component:

const fetcher = useFetcher();

// call fetcher
  const handleChange = useCallback(
    (e: string) => {
        fetcher.submit(
          { query: e },
          { action: `/data/get-address`, method: "get" }
        );
      }
    },
    [fetcher]
  );

// listen for fetcher response, dump the response in state, reset fetcher
 useEffect(() => {
    if (
      fetcher?.type === "done" &&
      fetcher?.data?.getAddress?.status === "fulfilled"
    ) {
      setOptions(
        fetcher.data.getAddress.value.map((address: FriendlyAddress) => ({
          value: address.id,
          label: address.address
        }))
      );
      resetFetcher(fetcher);
    }
  }, [fetcher]);

@jpbrown84 thanks for this workaround! I've been spending the last few hours pulling my hair out trying to figure out why my state kept acting weird, until I realized fetcher.data persists and there is no declarative way to reset it. (There really should be imo.)

Yes, make an action endpoint and have it return null. You'll get your action data reset to null that way.

Dou you have na exemple with this workaround?

@mandado You could try this awful workaround(I've been using this for a few project so far) to reset the fetcher.data.

import { useCallback, useState } from 'react'
import { type SerializeFrom } from '@remix-run/server-runtime'
import { type FetcherWithComponents, useFetcher } from '@remix-run/react'

type CustomFetcher<T> = FetcherWithComponents<SerializeFrom<T>> & {
  reset: () => void
}

export function useCustomFetcher<T>() {
  const [, updateState] = useState({})
  const forceUpdate = useCallback(() => updateState({}), [])

  const fetcher = useFetcher() as CustomFetcher<T>

  fetcher.reset = useCallback(() => {
    if (fetcher.data) {
      for (const key in fetcher.data) {
        delete fetcher.data[key]
      }

      fetcher.data = undefined
    }

    forceUpdate()
  }, [fetcher, forceUpdate])

  return fetcher
}

hope remix eventualy adds this as a native feature in future.

I wonder if this is more optimal, or less optimal than hitting an action that returns null.

I'd argue more because it doesn't cause a network roundtrip for updating local state

Thanks, I had to add another useEffect to act whenever myData is updated.

This still doesn't work for me, not sure if I'm doing this right but the following route should reset the fetcher data since the key is different, however it is not happening:

app/routes/$id.tsx

import { json } from '@remix-run/node';
import { Link, useParams } from '@remix-run/react';
import { useFetcher } from '@remix-run/react';

export const action = () => {
  return json({ test: 'This is action data' });
};

export default function Page() {
  const params = useParams();
  const fetcher = useFetcher({
    key: params.id,
  });

  return (
    <div>
      <h1>Fetcher Key: {params.id}</h1>

      {fetcher.data ? (
        <>
          <p>This shouldn't show on route change:</p>
          <pre>{JSON.stringify(fetcher.data)}</pre>
        </>
      ) : null}

      <fetcher.Form method="POST">
        <button>Submit then click "Link"</button>
      </fetcher.Form>

      <Link to="../test">Link</Link>
    </div>
  );
}

Demo: https://stackblitz.com/edit/remix-run-remix-gt3qmm?file=app%2Froutes%2F_index.tsx,app%2Froutes%2F%24id.tsx

@jahvi did you ever resolve this? Or find a decent workaround?

@andrewbarnesweb I didn't unfortunately 😔

This worked like a charm! thank you @sergiodxa

Edit: When using a Symbol as key, for some reason you lose the type-safety of the fetcher.

This works perfectly! I was using document reload before but thats no longer necessary! ❤️

Why it should? If the component is still mounted you won't expect states to reset, fetchers work that way.

Yeah maybe I'm using it the wrong way.

One thing that I have done to solve my problem was to create a random key for the fetcher and pass it to my subcomponents (only 2 so not a big deal) so every time I access the route its a new fetcher with no data.

If you have a route like parent.$childId, when you navigate from /parent/1 to /parent/2, the parent <Outlet> does not unmount. Basically, Remix is fetching the data for childId 2, and rendering your component. This is the something that would happened if you fetched manually.

An easy fix is to update your parent <Outlet> and use the current pathname as the key. This way navigations will automatically unmount.

// routes/parent.tsx
export default Component() {
  const { pathname } = useLocation()
  return <Outlet key={pathname} />
}

Interesting.

What I have now is something like this:

course.$courseId/modules/index+/_index.tsx - (uses useFetcher for loading state and error/success from fetcher.data)
course.$courseId/modules/index+/subcomponent_1.tsx - (uses useFetcher to execute an action)
course.$courseId/modules/index+/subcomponent_2.tsx - (uses useFetcher to execute an action)

(using fetcher to delete items from a list and reordering)

The origin of the discussion is the possibility of resetting the data of a fetcher instance, since the output is used to e.g. conditionally show a hint or toast message after submitting a form. The problem with this approach is, that the toast will never disappear, unless you completely destroy the component, in which the instance of the invoked useFetcher() originally resides.

@actraiser once the component unmounts, the fetcher will be queued to be deleted.

This is from react-router (which Remix uses under the hood):

  // Registration/cleanup
  React.useEffect(() => {
    router.getFetcher(fetcherKey);
    return () => {
      // Tell the router we've unmounted - if v7_fetcherPersist is enabled this
      // will not delete immediately but instead queue up a delete after the
      // fetcher returns to an `idle` state
      router.deleteFetcher(fetcherKey);
    };
  }, [router, fetcherKey]);

https://github.com/remix-run/react-router/blob/13ac1b6c5cc2c3f99629bed6ed0ccc8542de0d94/packages/react-router-dom/index.tsx#L1672-L1681

This idea is awesome. Can fix most of the problems I had and saw in any topic about this feature.

But what about instantiating a new fetcher?
Like exclusivelly handling the data with a different fetcher for a new fetching point?

That is the solution I ended up with.

Just explicitly generate one fetcher for each content you have.

a new hook = a new fetcher.
handle the global state of fetchers by hoisting all fetchers in a listner array.

the more code you write the safer you are from side-effects.

Any reason why you can't use the wrapper function I provided above?

#2749 (comment)

Or an alternative that adds support for fetcher keys. (I don't think fetcher keys were a thing when I wrote the wrapper)

#2749 (comment)

my biggest concern on using your approach @kiliman is that it hoists the function in react, and in its hooks, relying on double source of truth.
This is a double-edge-sword. We are violating the principle of single source of truth here.

On the other hand, the immutability on fetcher seems interesting concept, you fetched, the next time you fetch it changes the data, simple as that.

I would advocate that .reset should not be part of fetcher. 100 % with you.

Data belongs to storage layers, while fetching means fetching, you get the data from fetcher and do whatever you want with the data.

fetcher is not a storage hook. Handle your data appropriately.

@NavaceSystem Sorry for intruding, but it is not the word you described.
And with the new react on the horizon. Handle the data as youw ant.

Your fetcher can be a Pub/sub mechanism, but not a host of data.
Simple decompose into
Storage | Fetcher .

Use the fetcher to be notified about new data and as soon as your new data arrive, then update your storage. That is how this feature is intended to be used ( and all react to be honest. )

I generate a key based on the time the modal dialog opens. That way each dialog opening is a new fetcher. The dialog can also have logic that checks for errors and if not, closes itself.

this will cause each modal to save its keyed data in memory without being garbage collected, it’s hugely inefficient on top of it being a hack to a web native API.

@fredericoo When a key is no longer used the associated data is queued for deletion:

https://github.com/remix-run/react-router/blob/79241a86c7c77c91772a89e3944db6360cd3e9bf/packages/react-router-dom/index.tsx#L1704-L1712

I've not had any problems with this approach of generating new keys for each new fetcher.

This works for me:

import { useCallback, useMemo, useState } from 'react';



import { uniqueId } from 'lodash-es';

import { useFetcher } from '@remix-run/react';

export function useResettableFetcher<T>() {

  const [fetcherKey, setFetcherKey] = useState(uniqueId());

  const fetcher = useFetcher<T>({ key: fetcherKey });



  const resetFetcher = useCallback(() => setFetcherKey(uniqueId()), []);



  return useMemo(() => [fetcher, resetFetcher] as const, [fetcher, resetFetcher]);

}

react has useId no need for lodash and use state slop

You are of course right that there's no need for lodash's uniqueId specifically, but useId won't work since it does not allow you to generate a new ID on reset.

I don't get why no one is using or suggested calling fetcher.data = undefined. That seems to be working fine for me.

There are many things that can work if you use extra state to trigger a render of the page. Your suggestion only works if you have an extra useState variable to force a rerender. Just doing fetcher.data = undefined by itself does not rerender the page with the new data value. As I understand it the stated goal is to avoid extra useState or useMemos for basic features. Because fetcher is intended to be a form handler, it should handle the basic feature of a form reset without needing extra ad hoc state or effect handlers to accomplish this.

Here is a new minimal reproduction with a checkbox to trigger a forced rerender:

https://stackblitz.com/edit/remix-run-remix-ijlmjxg3?file=app%2Froutes%2F_index.tsx