[Feature]: Add fetcher.reset() to reset the fetcher

[dipeshhkc]

What is the new or updated feature that you are suggesting?

Reset the fetcher data returned from the action? Using something Like fetcher.reset()

Why should this feature be included?

Example Flow would be

1. Submitting form like

fetcher.submit(
      {
        email: "[email protected]",
      },
      { action: "/api/user", method: "post" }
)

2. We get data like fetcher?.data?.formError from the action
3. Now after a certain event like the user clicks on dismiss error or something similar, I want to reset fetcher data returned from action.

Yeah there can be a workaround like

• once we get fetcher.type === "done" && fetcher.data.error then set a client-side state with fetcher?.data?.formError and use this state instead of fetcher?.data?.formError in UI. Now we have full control over the error message.

But doing this manual work in every component is a little annoying.

https://www.loom.com/share/f20262a4773d460c9f4d962cc8880431

In the video,

1. There is an error message from action which is displayed on the modal form
2. I close the modal
3. When I reopen the modal, the old error message exist

Here If I could do like fetcher.reset() on closing the modal, that would be awesome. [Though I have no idea how hard is it to implement or even if it possible to implement this 😅]

Let me know if something awesome exists that solves this problem without needing to maintain a state on the client side. 🙇

[WesleyKapow]

Just hit this myself for the exact same use case -- I have a modal, the user gets errors on submit and hits cancel. When they re-open the modal the fetcher.data is still the old data and thus they'll see form errors again!

I want fetcher.reset()!!

[Merott]

Running into a similar issue with stale data in the render function causing this wonkiness:

I don't understand. What's even useful about previous data when I'm calling fetcher.load() with different query params?

I tried wrapping useFetcher with a custom hook, but I've had no success in taming .data so far.

Has anyone figured out a clean solution that doesn't require managing data in multiple places?

(and hey @WesleyKapow 👋 … small world!)

[jgangemi]

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.

[Merott]

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.

[jpbrown84]

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]);

[andersr]

@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.)

[doytch]

Yeah...would love this.

Generally people have suggested workarounds like moving the data fetching further down the component tree but that tends to either break container/display-component patterns or make them unwieldy like ContainerComponent -> ContainerComponent -> DisplayComponent

[thosmos]

The nice thing about using the fetcher is being able to directly link a simple component's UI to the .data field, but without the ability to reset it this has limited usefulness due to needing to add a layer of extra local state on top of it, which the fetcher has the potential to eliminate.

https://stackblitz.com/edit/node-9ta3ig?file=app/routes/index.tsx

Here's a simplified version of a form I made today that brought this up for me. It's a 2 phase contact signup + verification form, where state from the previous submit is round-tripped in order to activate (and be submitted with) the 2nd phase of the form. This could be done with 2 forms/fetchers instead, and it might be more clear that way, but even in that case, if the visibility of the 2nd form/phase is dependent on the .data of the first, then we need a way to reset the data of the first in order to get back to a clean form state. Resetting the DOM form with a ref is not good enough.

[mandado]

is there any workaround to reset fetcher ?

[mercpls]

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

[mandado]

Dou you have na exemple with this workaround?

[jpbrown84]

const handleStartNewConversation = useCallback(() => {
    newConversationFetcher.submit(
      {
        deviceId,
        medium: "chat"
      },
      { action: "/data/create-support-ticket", method: "post" }
    );
  }, [newConversationFetcher, deviceId]);

  useEffect(() => {
    if (
      newConversationFetcher.data?.createSupportTicket &&
      newConversationFetcher.type === "done"
    ) {
      setCurrentTicketDetails(newConversationFetcher.data.createSupportTicket);
      resetFetcher(newConversationFetcher);
    }
  }, [newConversationFetcher]);
  
//////////
  
// Helper file:

import type { FetcherWithComponents } from "@remix-run/react";

// eslint-disable-next-line @typescript-eslint/no-explicit-any
export const resetFetcher = (fetcher: FetcherWithComponents<any>) => {
  fetcher.submit({}, { action: "/data/reset-fetcher", method: "post" });
};

//////////

// Reset route:

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

[arielvieira]

@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.

[cblauvelt]

I investigated what it would take to implement this and it needs to be done within react-router-dom since remix creates a wrapper around that. I have added a feature request here remix-run/react-router#10231.

I was able to work around this by mounting and unmounting the component based on what I was using for a visible state. I don't think this is optimal but it gets the job done. I was inspired by the route-modal example which may also solve this issue, at least for now.

[mercpls]

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

[reconbot]

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

[jahvi]

Another workaround I've used is to not use the value in fetcher.data directly but to set a new value with useState and use that instead like:

const [myData, setMyData] = useState();

useEffect(() => {
    if (fetcher.state === "submitting" || fetcher.state === "loading") {
      setMyData(undefined);
    } else if (fetcher.state === "idle") {
      setMyData(fetcher.data?.myData);
    }
}, [fetcher.state, fetcher.data]);

// Use `myData` instead of `fetcher.data.myData`

Kind of ugly but it works if you don't have too much data to worry about and don't want to create a reset route for whatever reason.

[ifigueroap]

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

[charesbast]

You could also reload the page to reset the action data (and clean it from previous validation error fields)...
Not the most optimal solution but it works without any custom workaround.
(That's what I did personnally)

const navigate = useNavigate();
const location = useLocation();

...

<button
  className="ml-auto"
  onClick={() => {
    setIsEditing(false);

    // -> to reset potential action validation errors
    navigate(location.pathname);
  }}
>
  Annuler
</button>

[kiliman]

Here's a working fetcher with reset()

export type FetcherWithComponentsReset<T> = FetcherWithComponents<T> & {
  reset: () => void;
};

export function useFetcherWithReset<T>(): FetcherWithComponentsReset<T> {
  const fetcher = useFetcher<T>();
  const [data, setData] = useState(fetcher.data);
  useEffect(() => {
    if (fetcher.state === "idle") {
      setData(fetcher.data);
    }
  }, [fetcher.state, fetcher.data]);
  return {
    ...fetcher,
    data: data as T,
    reset: () => setData(undefined),
  };
}

⚡️ StackBlitz https://stackblitz.com/edit/remix-run-remix-vhgfqt?file=app%2Froutes%2F_index.tsx

[MuraraAllan]

Not much related, but seems usefull to share...

Instead of reseting it, I trust in the last "loading" state and wrap the fetcher in a global Provider, all around my application, then fetch through a hook.
You can always put the same reset method said before.

The loading state of the fetcher has a last "handshake" step, where it asks for the data chunk while in loading.

So I never trust in iddle fetchers, but in the last step of the handshake. (loading + data chunk)

The state transition on the fetcher works so it gets the data from the fetcher in "loading" state still, and considers it done after that ( iddle ). So you get a mirrored result on fetcher.data. One for loading with data and the first one for iddle with data.

Whenever you have a data chunk in "loading" state, means that it is the last handshake of loading state.

[sergiodxa]

I think with the new useFetcher({ key }) (#7698) this will be solved, just pass a new key and you will have a new fetcher instance. Example here #7698 (comment).

[jahvi]

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

[andrewbarnesweb]

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

[jahvi]

@andrewbarnesweb I didn't unfortunately 😔

[Jesus-fhz]

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.

[LeftoversTodayAppAdmin]

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

[cleytoncarvalho]

Having the same problem while implementing a toast message:

1 - Delete an item
2 - Show toast message
3 - Open another link
4 - Click link to go back to previous page
5 - Toast message shows up again

Maybe using a different fetcher key would solve the problem but I need the key to be the same so I can show some loading state in a component separated from the route and the toast itself

[cleytoncarvalho]

btw why doesn't the fetcher resets its data when the route change?

[sergiodxa]

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

[cleytoncarvalho]

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.

[kiliman]

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} />
}

[cleytoncarvalho]

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)

[arunmmanoharan]

Modified @kiliman's solution with a fetcher key.

https://gist.github.com/arunmmanoharan/38d313f28dc17637a0e3cfa8c6205bd5

[patrick-schneider-latori]

You can also use a useState value for the useFetcher key. Resetting this value to a new one also resets the fetcher, since it listens to the actual state of the value.

See my example code:

function ExampleComponent() {
  const [key, setKey] = useState("a123");
  const fetcher = useFetcher({ key });
  const [showModal, setShowModal] = useState(false);
  const [dataChanged, setDataChanged] = useState(false);

  function handleShowModal() {
    setShowModal(true);
  }

  function handleCloseModal() {
    setShowModal(false);
  }

  useEffect(() => {
    if (fetcher.state === "idle" && fetcher.data?.ok && !!fetcher.data?.msg && !dataChanged && showModal) {
      setDataChanged(true);
    }
  }, [dataChanged, showModal, fetcher]);

  useEffect(() => {
    if (dataChanged && !showModal) {
      setKey("b321");
    }
  }, [dataChanged, showModal]);
  
  useEffect(() => {
    setDataChanged(false);
  }, [key]);
  
  return (
    <div>
      <button type="button" onClick={handleShowModal}>Show Modal</button>
      <Modal show={showModal} onClose={handleCloseModal}>
        <>
          {dataChanged ? (
            <div>Data has been changed</div>
          ) : (
            null
          )}
          <fetcher.Form method="post">
            <input type="email" name="email" />
            {!dataChanged ? (
              <button type="submit">Change E-Mail</button>
            ): (
              <button type="button" size="small" onClick={handleCloseModal}>Close Modal</button>
            )}
          </fetcher.Form>
        </>
      </Modal>
    </div>
  );
}

[actraiser]

What is the actual overhead of using random keys and with that creating new fetchers all over the place? Say, I have a message board where people use an editor to create or edit posts. Also let's say, the editor uses useFetcher({ key: 'edit-' + Date().toISOString()}) which over the lifetime of a session could create dozens if not hundreds of fetchers in that client. Is this even noticeable?

Greets
-act

[patrick-schneider-latori]

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.

[kiliman]

@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

[aCanalez]

The Link component you can provide a reloadDocument prop which will reset the state of fetcher. fetcher.data will be undefined in this case. Hope this helps anyone running into this issue.

[hilja]

I thought I needed a way to reset the fetcher, but adding more entropy to the key fixed it. A param did the job in this case, just go to town with that key. Hope this helps anyone.

const params = useParams()
const fetcher = useTypedFetcher<typeof fragmentLoader>({
  key: `filter-${cat}-${params.urlId}`,
})

[MuraraAllan]

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.

[NavaceSystem]

The reset via key trick works but having a native .reset on the fetcher would make this so much simpler. We have screens where we have multiple fetchers for submitting tiny actions and it's a pain in the ass to maintain and use a key per fetcher.

[kiliman]

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)

[MuraraAllan]

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.

[MuraraAllan]

@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. )

[fredericoo]

Just hit a wall where I want a modal to close when the fetcher data submits successfully but not when it errors, and as the state persists I can’t open it ever again 😆

@ryanflorence pls

[ngbrown]

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.

[thosmos]

I think there’s a baseline concept here that’s getting missed. The idea with a form fetcher is to link an html form to some remote endpoint. The thing getting missed is that the native form has a reset(), but the fetcher doesn’t. It’s a missing feature. Someone asserted here that the point is just to update local state and that it shouldn’t be used directly. If so then this requires extra useState or useEffect magic which Ryan has claimed is his goal to avoid. It seems like such a small and obvious thing I’m actually quite surprised there’s so much debate about it. T

…

On Mon, Oct 14, 2024 at 8:22 AM ✦ freddie ***@***.***> wrote: Just hit a wall where I want a modal to close when the fetcher data submits successfully but not when it errors, and as the state persists I can’t open it ever again 😆 @ryanflorence <https://github.com/ryanflorence> pls — Reply to this email directly, view it on GitHub <#2749 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEXVZV2FALZQSXIGNIGRB3Z3POU3AVCNFSM5WZ73QGKU5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMBZGM4DGNZY> . You are receiving this because you commented.Message ID: ***@***.***>