SetStateAction returned from useState hook dose not accept a second callback argument

[cheungseol]

Do you want to request a feature or report a bug?
Question

What is the current behavior?
The SetStateAction returned from useState hook dose not accept a second callback argument. It cannot works like Class Componet's 'setState' method, which receives a callback param, and can perform the callback after this setState action updates;

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:
https://codesandbox.io/s/93mkr1ywpr

What is the expected behavior?
Hopes the SetStateAction function can receive a second callback argument, and can used like 'setState' method callback.

I have read the official note:

// this technically does accept a second argument, but it's already under a deprecation warning
// and it's not even released so probably better to not define it.

If instead it's working as intended, how can I perform special action after this SetStateAction called ?

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
16.7.0-alpha.0

[gaearon]

Is there a reason you can't useEffect instead? Generally it's a better solution.

[cheungseol]

Is there a reason you can't useEffect instead? Generally it's a better solution.

Since I don't want to trigger callback action every time after dispatching a SetStateAction. But 'useEffect ' might cause the effect running every time after the state changed.

[Jessidhia]

Use a useRef for setting a flag saying you want the effect to run, or just do the effect directly in the function where you're calling setState, as you shouldn't be doing it in the render phase to begin with.

[gaearon]

Since I don't want to trigger callback action every time after dispatching a SetStateAction. But 'useEffect ' might cause the effect running every time after the state changed.

Can you describe a more specific use case please?

[therayess]

@gaearon
Hi, i also faced similar issue where i needed to add a callback for when the state is set, my scenario is this:
I make an api call, after i get the response, i update a context state item, then i take the user to a new page (pushing to history), currently, without the callback, i get a warning that says:

Warning: Can't perform a React state update on an unmounted component.

Basically, i'm running a setState on a component that has been unmounted due to the page change.

Ideally, i would like to update the context (or any callback function from parent component for example), then once that process is done, run the callback that will apply the page change.

This could've been done easily with the setState(state, [callback]).

Please advise, thanks for your time!

[therayess]

I found the solution, we can actually await the set function 👍
Thanks

[mbohgard]

@therayess Where is it documented that the set function of useState returns a promise?

[jquense]

It doesn't, you can technically await anything in js, but that doesn't really mean anything in this case, it's not waiting until the state flushes to resolve

[therayess]

You are right, apologies for that, it worked for another reason, is there a way to achieve a state set callback with useState ?

[joshburgess]

Being able to pass a callback to useState's returned setState would allow for greater flexibility. For example, we could implement a dispatch function that takes a callback to fire off post-reducer-update, like UpdateWithSideEffects in Reason-React: https://reasonml.github.io/reason-react/docs/en/state-actions-reducer#state-update-through-reducer

ReasonReact.UpdateWithSideEffects(state, self => unit): update the state, **then** trigger a side-effect.

Right now, it's possible to implement a Redux-like architecture with an added "hook" for running effects AFTER the reducer update with the class API, Context, and this.setState's callback param, but to accomplish the same thing with react-hooks means needing to use useRef or useEffect + extra boilerplate (setting & checking flags to control when the effect is allowed to run).

Today, in Redux-land, people use middleware libraries like redux-saga, redux-observable, redux-loop, etc. to be able to declaratively describe async effects via dispatched actions, because Redux doesn't expose an API function for running effects after a reducer update, but it's not difficult to implement this sort of functionality with the class API & setState's callback param. We could do something similar with react hooks if useState's setState or useReducer's dispatch accepted a thunk param describing a one-time effect we'd like to run.

This one-time, post-update effect feature could be implemented by offering different variations of "dispatch", like how Reason-React has SideEffects and UpdateWithSideEffects in addition to NoUpdate & Update. Having these separate versions of "dispatch" instead of a single "dispatch" dynamically overloaded with optional params is nice, because it allows us to be more explicit about our intentions & the static types being passed around.

Alternatively, instead of having different variations of dispatch, some of which allow for this post-update effect hook, imagine a simple effect system with just a single dispatch function, but where your dispatched actions could contain an extra key called effect, either at the top-level, or, perhaps, under meta for FSA users, where the value is a thunk or some other lazy async data structure we want to execute. I've personally implemented this idea using the class API & setState's callback param and found it pretty useful. If there were some way to provide a callback to useReducer's dispatch function that had access to the dispatched action, this sort of thing could be implemented in user-land with hooks.

[Jessidhia]

Untested madness that I'd rather not touch...... but it's an idea, and I have no idea if it works. But it typechecks 🤷‍♀️

import React from 'react'

function useImperativeEffectsFactory(serialized = true) {
  const [, internalSetEffect] = React.useState<Promise<void> | undefined>(undefined)
  return React.useCallback<(effect: () => Promise<void> | void) => void>(
    effect => {
      internalSetEffect(current => {
        const promise = (async () => {
          try {
            if (serialized) {
              await current
              await effect()
            } else {
              await Promise.all([current, effect()])
            }
          } finally {
            internalSetEffect(current => (current === promise ? undefined : current))
          }
        })()
        return promise
      })
    },
    [internalSetEffect]
  )
}

const useImperativeEffect = useImperativeEffectsFactory()

useImperativeEffect(async () => {
  // ...
})

[joshburgess]

@Kovensky I just tried it out, and that code results in a Too many re-renders. React limits the number of renders to prevent an infinite loop. error. Might be a simple problem, not sure. Haven't tried to debug it yet.

Anyway, I'm not saying that there aren't other ways to implement the same idea with Hooks, but it does seem like a lot of hoops need to be jumped through in order to do the same thing that currently is possible with the class API's setState just by passing in a function as an extra param.

[basbz]

I think @joshburgess has a good point!
Having the callback would make it easier to express side effects like the way it's done in ReasonReact https://github.com/reasonml/reason-react/blob/de0803fa5784e434e3d9da374ec3e4e8a7653f12/src/ReasonReact.re/#L591
or in React ReComponent https://github.com/philipp-spiess/react-recomponent/blob/6c75e1ce99238af0db3389c25a2ca0cee5fa8207/src/re.js#L96
And would enable isolating state even more from classes or components that us it.