Run mutation on page load

[devuxer]

I want to have a mutation run when a page loads. Would you recommend putting a mutate() call inside a useEffect in this case or is there a better way?

My use case is a user clicking a link in a transactional email to verify their email account.

[justinthareja]

@devuxer how did you end up solving this?

I've recently run into this issue myself. I'm still new to the react ecosystem, and for various reasons my click handler needs to be wrapped in a useCallback. So right now the code looks like:

// custom react-query hooks as per recommendation
function usePlay() {
  const { user } = useUser();
  const mutation = useMutation((options) => spotifyApi.play(options));
  return user ? mutation : stub;
}

function usePause() {
  const { user } = useUser();
  const mutation = useMutation(() => spotifyApi.pause());
  return user ? mutation : stub;
}

// consuming custom hooks
const pause = usePause();
const play = usePlay();

const playPauseHandler = useCallback(() => {
    if (status.state === "playing") {
      pause.mutate();
    } else {
      play.mutate({
        uris: [`spotify:track:${item.id}`],
        position_ms: progress,
      });
    }
  }, [item.id, status.state, progress]); `` // how can i properly include mutate here?

I'm still trying to wrap my head around hooks and react-query. Is it ok to omit the mutate function from the dependency array? If I include it, I believe there is an infinite re-render cycle because mutate !== mutate for each cycle. It seems to work as expected if I exclude it.

From my limited understanding I could somehow properly include mutate in the dep array by wrapping it in it's own useCallback somehow? Still a little fuzzy on this, please advise.

[reorx]

@IanVS Sound similar to a newsletter unsubscription process. Users would appreciate not having to click the button again. Very reasonable, now I'm not 100% sure about the philosophy that "Mutations should be side-effects of user interactions" 😂

[TkDodo]

Sound similar to a newsletter unsubscription process.

I mean yes, but why does this need client side mutation at all? If I go to the yourservice.com/unsubscribe page, I would expect to be unsubscribed immediately (that means: the server does it, right away).

having this page be a client side page that needs javascript to actually perform the unsubscribe with a client side request on-mount seems wrong. I guess this is one of the reasons why react tries to push us towards frameworks like next/remix. None of this needs to happen on the client if we have a server.

[reorx]

@TkDodo I have had the same question for many years, and I have always hated it. But one day, I realized that the reason behind this phenomenon is likely to avoid unintentional unsubscribing due to anti-spam mechanisms. Some email clients may visit the links in the email to check if they're unsafe. Of course, this case does not apply to those who deliberately make the unsubscribe process difficult for users.

@IanVS Are you not generating the authentication code on the server side for the same reason?

[IanVS]

@reorx this seems a bit off-topic for this thread, but yes the code is generated by the server, in response to a POST request.

[mrclrchtr]

As @TkDodo advised, one can use mutationState.

But I agree overall that it should be done on the server side.

Nevertheless, here is the solution with mutationState:

const hasFired = useRef(false);
const confirmSignUp = useConfirmSignUpMutation();

const mutationState = useMutationState({
    filters: { mutationKey: [MUTATION_KEY_CONFIRM_SIGN_UP] },
    select: (mutation) => mutation.state.status,
});

useEffect(() => {
    // Only trigger mutation once, even if useEffect fires more times
    if (confirmSignUp.isIdle && !hasFired.current) {
      hasFired.current = true;
      confirmSignUp.mutate(token);
    }
}, [token, confirmSignUp]);

....

return (
    <Container size={420} my={40}>
      {(() => {
        switch (mutationState[0]) {
          case "idle":
            return confirmSignUpPending;
          case "pending":
            return confirmSignUpPending;
          case "success":
            return confirmSignUpSuccessful;
          case "error":
            return confirmSignUpError;
        }
      })()}
    </Container>

[TkDodo]

putting mutate or mutateAsync in a useEffect is fine. Just be prepared that the mutation will run whenever the component mounts. Not sure what the use-case is for that, but there might be some :)

The mutate and mutateAsync functions should be stable across re-renders so there is no need to omit them from the dependency list of the effect (which is something you generally shouldn't be doing imo)

My use case is a user clicking a link in a transactional email to verify their email account.

I don't really see why for this use-case, you need to make a request from the frontend:

• user requests page, token or so is probably in the url
• page loads
• you make a mutation onMount

I would just do:

• user requests page, token or so is probably in the url
• backend reads the url, validates the email
• delivers page to frontend, user is validated or not 🤷‍♂️

[chiptus]

@TkDodo am I right to assume that although mutate is stable, the result of useMutation isn't?

for some reason, eslint shouted at me when I put useMutationResult.mutate in the dependency list and it expected me to put the whole result object as a dependency which caused numerous mutations. while doing:

const {mutate} = useMutationResult

useEffect(() => {
	mutate()
}, [mutate])

worked. any idea why?

[TkDodo]

am I right to assume that although mutate is stable, the result of useMutation isn't?

yes, that's right.

any idea why?

I have seen that as well, my best guess is that its a shortcoming of the lint rule :(

[TkDodo]

i think it's this:

• Warning for 'exhaustive-deps' keeps asking for the full 'props' object instead of allowing single 'props' properties as dependencies facebook/react#16265

[chiptus]

thanks for the quick answer!

[chiptus]

and here's the response facebook/react#16265 (comment) which makes sense

[vashisth00]

Any other solution for this? 👎🏻

[tonypee]

useEffect seems like the right place, as triggering the mutation is an imperative action, which can be called at any time - on the useEffect is a particular time. You just need to decide if that is the time you want

[lamualfa]

If you want to run the mutation just once when using React StrictMode, you can do this:

const mutation = useMutation()

useEffect(() => {
   if(mutation.isIdle) {
      mutation.mutate()
   }
}, [])

[yairopro]

A little bit dirty (since a state is created when not needed) but does the job

const mutation = useMutation(...);
useState(mutation.mutate); // run only once per component

[yairopro]

Sorry to say but useMutation should have a way to be run at mount (in strict mode). 😂

[TkDodo]

sorry to say, firing a side-effect depending on when a component renders or not doesn't seem to play well with how react envisions side-effects 🤷‍♂️

[yairopro]

Hi @TkDodo :)

Maybe I am wrong, but the react strict-mode fires side-effects twice in development in order to help them to be robust to re-renders and re-mounting (forcing us to deduplicate them I guess) before production.
That's why having a useMutation() with an option to run it on mount (and deduplicate it with something like a nonce 😇🙈) can then indeed play well with how react envisions side-effects.

[TkDodo]

directly from the react docs:

Code that runs because a component was displayed should be in Effects, the rest should be in events.

That's the reason strict mode runs everything multiple times. There are new APIs coming in React19 that might fire your effects more often in production as well, e.g. when something goes out of screen or becomes visible again after it has been hidden behind a Modal Dialog (used to be called offscreen API, now will be called Activity).

So they really want you to think about if your effect is related to a component being rendered / shown, or if you're just doing that because you think it's the best "lifecycle" to hook into. Usually, mutations don't fall into that category. You usually don't want to fire a mutation because a component renders - you want it because the user interacted with something in your app. One exception imo is tracking pageViews to an analytics API. But there it doesn't matter if it fires twice in devmode, as it won't be fired doubled in production (e.g. if you have an effect in your top page component).

[yairopro]

THank you
You rock

[tonypee]

Tony Polinelli

…

On Wed, 20 -aaaa1-Mar 2024 at 8:07 pm, Yair ***@***.***> wrote: 1. const mutation = useMutation(...);useState(mutation.mutate); // run only once per component — Reply to this email directly, view it on GitHub <#986 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXRUNLUX3HXWRYMGO65JCLYZFNXNAVCNFSM4RAPKD62U5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TQOBVGA4DEMI> . You are receiving this because you commented.Message ID: ***@***.***>

[devuxer]

So they really want you to think about if your effect is related to a component being rendered / shown, or if you're just doing that because you think it's the best "lifecycle" to hook into. Usually, mutations don't fall into that category. You usually don't want to fire a mutation because a component renders - you want it because the user interacted with something in your app. One exception imo is tracking pageViews to an analytics API. But there it doesn't matter if it fires twice in devmode, as it won't be fired doubled in production (e.g. if you have an effect in your top page component).

In my case, it's that I want to fire a mutation because the user clicked on a link in a transactional email to, say, reset their password, and I want to fire a mutation due the action of the user clicking that link the email. Since I can't tie into that user action from the email client, I tie it to the page loading in the browser, than I display the appropriate message in the browser (success, link expired, or whatever).

[TkDodo]

Usually I would say: Let the server handle this when the specific route is accessed. But even if you do client side only, you can fire a request when the bundle evaluates, outside of the react lifecycle. Or really, just do it in a useEffect in the top level component that you pass to root.render:

const root = ReactDOM.createRoot(rootElement)
root.render(
  <>
    <React.StrictMode>
      <App /> 
     </React.StrictMode>
     <SomeComponentThatRendersNullAndFiresAMutationInUseEffect />
  </>
)

really, an effect there is fine ...

[devuxer]

Thanks @TkDodo!

This is a NextJS app (w/ pages folder), and the effect is at the page level, which is the top-level component, so I think I'll just stick with my current useEffect solution for now. Helpful to get your take on these alternatives, though!

[TkDodo]

if you have a server, why do you need to "fire a mutation because of the action of the user clicking that link in the email" from the browser? You have a server. The user clicks the link, it navigates to https://my-app/rest-password. That could be an API route that does what you want the mutation to do, then redirect to a page. Or, it would be a page that does what the mutation would do in getServerSideProps...

[devuxer]

if you have a server, why do you need to "fire a mutation because of the action of the user clicking that link in the email" from the browser?

Honestly, that would probably work fine, but at the time I built this feature, I didn't know better (and no one responded to my original post here for half a year) . Fast forward to today, and I'm a little reluctant to mess with it as long as it's working. but I may tackle it as a learning experience. It seems like I'd need to handle the request at the server and then serve one of several different pages (or perhaps a single page with a query string) to provide feedback to the user on whether the operation was successful or not. I'd love to see a relevant example in NextJS to see how this would be done.