[hooks] useState - "setState" callback

[marcellomontemagno]

Hi, I'm very hyped about the hooks api and I started experimenting with it on some small side project.

I've noticed that the "setState" function returned by the useState hook doesn't have an "afterRender" callback (the second argument of this.setState in classes)

I didn't find further informations about this in the doc. Is there any design reason why the "afterRender" callback is not present? Is there a plan to introduce it later on?

The reason I ask is that during the past years of react usage I found a few scenarios (very rarely though) were not having the "afterRender" callback would result in a quite tedious implementation of componentDidUpdate or pushed me to change the shape of my state to work around it (I can provide examples about this)

In the meanwhile here the snippet I used to understand that no "afterRender" callback is used by the "setState" of hooks

Counter.js

import React, {useState} from 'react';

export const defaultState = {count: 0}

export const useCounter = () => {

  const [state, setState] = useState(defaultState)

  return {
    ...state,
    onIncreaseCounter () {
      setState({...state, count: state.count + 1}, () => {console.log('++++++++++++++++++')})
    },
    onDecreaseCounter () {
      setState({...state, count: state.count - 1}, () => {console.log('++++++++++++++++++')})
    }
  }

}

export default function Counter ({count, onIncreaseCounter, onDecreaseCounter}) {
  return <div>
    {count}
    <button onClick={onIncreaseCounter}>+</button>
    <button onClick={onDecreaseCounter}>-</button>
  </div>
}

Root.js

import React from 'react';

import Counter, {useCounter} from "./Counter";

export default function Root () {
  return <Counter {...useCounter()}/>
}

the log never appears in the console after after increasing and decreasing the counter

[jquense]

@sandiiarov that won't do what @marcellomontemagno is asking, it just logs immediately, not in the callback.

@marcellomontemagno you can use a useEffect hook to do 'after render' callbacks and coordinate with the current state value

[gustavo-depaula]

Yes, there is not a second argument on the setState hook callback. +1'd because I also want to know the reason why.

[renatoagds]

@marcellomontemagno agree with @jquense to use useEffect, since setState will cause a re-render and it will call useEffect.

[heyimalex]

Could someone write an example? Imagine a list of items that a user can cursor through. Whenever we get a keydown event on an arrow we update the cursor position, and then in the callback we scroll the currently selected element into view.

const itemCount = 10;
const [cursor, setCursor] = useState(0);
const handleKeyDown = e => {
  if (e.key === 'ArrowUp') {
    setCursor(cursor => Math.max(0, cursor - 1), () => {
      // scroll element into view
    });
  } else if (e.key === 'ArrowDown') {
    setCursor(cursor => Math.min(itemCount - 1, cursor + 1), , () => {
      // scroll element into view
    });
  }
}

Lets also say that arrow keys aren't the only reason that cursor changes, but are the only reason we want to scroll. It seems like we'd need to track some extra state to make this work with useEffect.

const itemCount = 10;
const [state, setState] = useState({ cursor: 0, scrollKey: 0 });
const handleKeyDown = e => {
  if (e.key === "ArrowUp") {
    setState(state => ({
      cursor: Math.max(0, state.cursor - 1),
      scrollKey: state.scrollKey + 1
    }));
  } else if (e.key === "ArrowDown") {
    setState(state => ({
      cursor: Math.min(itemCount - 1, state.cursor + 1),
      scrollKey: state.scrollKey + 1
    }));
  }
};
useEffect(
  () => {
    if (state.scrollKey > 0) {
      // scroll to current element
    }
  },
  [state.scrollKey]
);

Does that look about right?

[MohamedLamineAllal]

Same here, i find the callback very useful. Too i can't imaging a scenario why this should be removed. Or how it influence performance. I really want to know the why ! For me i just though it's a one call or a resolve of a promise. That will happen when the updates happen. I don't know but it's seem that there is more to it. facebook/react#14174 (comment) (this thread is treating that better). So i guess i've got to look at how the hooc model is implemented and work.

However combining with useEffect. we can use a promise, that we resolve in useEffect. And keep more of the flexibility. Even thogh not too cool.

Check this (a more lively thread, with a lot of context) #68 (comment)

[phryneas]

Because it invokes a thought pattern that may very well be an antipattern with hooks.

With hooks, you are writing code more declarative than imparative.

The thought of "do one thing THEN do another thing THEN do another thing" would be the imparative (here: callback- or promise-based) way.

What actually should be done in the hooks model would rather be a "if this has been rendered, and this property is different than before, X should be done to reach the target state", which is more declarative. You don't designate when stuff happens, but just give a condition/dependency and let react pick the right point in time for it.

[jamesplease]

Folks may already know all of/some of this, but I figured I'd post it just in case. The warning that's logged when trying to use the 2nd callback argument provides a hint as to why it isn't supported:

Judging from the message, it seems that using useEffect is preferred instead, which is an alternative @jquense mentioned above .

Here's a CodeSandbox example of the Counter from the initial post using useEffect: CodeSandbox link

And also just to clarify again, I know you may already know all of this @marcellomontemagno but since hooks are new-ish I figured I'd post this just in case! 😅

[alex35mil]

What actually should be done in the hooks model would rather be a "if this has been rendered, and this property is different than before, X should be done to reach the target state", which is more declarative. You don't designate when stuff happens, but just give a condition/dependency and let react pick the right point in time for it.

This reminds me of a game "guess what to do in componentWillReceiveProps by comparing N different things".

---

I have a form library and I'm thinking of how to update it to the new API. I'm just getting myself familiar with hooks and got stuck pretty soon on the following case: user submits a form.

In the previous class-based model, when Submit action is dispatched, I update a state and trigger onSubmit effect, using setState callback (UpdateWithSideEffects callback in Reason). Simple as that.

In the hooks world I can't do that. I have a reducer that returns a state only and useEffect that runs (or not) on each re-render independently. Schedule of useEffect can be managed by specifying array of deps and if one of the deps has changed, effect is triggered. So, if I understand docs correctly, I need to:

1. find a value in state that is changed on Submit and pass it to deps array: this is a form status
2. inside effect, check if current value of form status is Submitting then trigger onSubmit handler

Here's the first confusing point: what if re-render was triggered during submission for some unrelated reason (e.g. parent props was updated due to whatever). In fact, submission request was triggered and is ongoing but since re-render was triggered and form status is still Submitting -> all conditions are met to re-run effect.

This common case seems pretty tricky with hooks. But hopefully I just didn't grok it yet and there is clean way to handle it within the new model.

[phryneas]

Usually, I'd trigger the asynchronous side-effect directly from button.onClick or form.onSubmit and store the results back using a useReducer dispatch. Since that seems not to be an option for you, maybe do something along these lines?

depend only on isSubmitting, pass state via Ref

const [state, dispatch] = useReducer(...);
const stateRef = useRef();
stateRef.current = state;

useEffect(() => {
  if (!state.isSubmitting) { return; }
  // do your submitting with stateRef.current in here
  // then dispatch the results
}, [state. isSubmitting]);

The effect only triggers when state.isSubmitting changes and within it, you have access to the latest state using the ref. Though I would not recommend using this reference hack in every situation, in your case it seems fitting.

But keep in mind: if you have a promise chain in your useEffect and access the stateRef later (with a few renders in between), you might access a later version of the state, not the state at the time the effect was triggered

Or, you omit the reference here, that way you would have access to the state at the time of triggering the effect - but you would have eslint-plugin-react-hooks linter warning that you might need to ignore.

depend on full state, keep track of last submit in a Ref

in this case, we assume a property state.submitCount that is increased by 1 with every submit

const [state, dispatch] = useReducer(...);
const lastSubmittedRef = useRef(0);

useEffect(() => {
  if (lastSubmittedRef.current === state.submitCount) { return; }
  lastSubmittedRef.current = state.submitCount;
  // handling here
}, [state]);

[alex35mil]

I spent some time today on this and ended up with using custom hook that brings back UpdateWithSideEffects to hooks with almost zero changes to initial reducer: https://github.com/alexfedoseev/re-formality/pull/51/files#diff-376207e44be3824884705dd487fd098c

Looks like it works. All props to @bloodyowl for initial gist: https://gist.github.com/bloodyowl/64861aaf1f53cfe0eb340c3ea2250b47

[rwieruch]

Yes, you can use useEffect/useLayoutEffect to add your custom callback function after updating state. If you are looking for an out of the box solution, maybe this custom hook which is nothing else than useState with a callback function may be handy for you.

[slorber]

@rwieruch your code is dangerous, everytime the callback changes (which does happen frequently if using closures) the callback will fire again. You need to "stabilize" your callbacks using refs (Dan Abramov has a nice blog post somewhere on that topic)

[kdzhambazov]

I understand that from a general case point of view useEffect() will run our code on the place of the old setState() callback, however consider this case:

...
onChange() {
...
this.setState(stateToSet, () => {
if (this.props.parentOnChange) {
this.props.parentOnChange(this.state);
}
});
....
}

onBlur() {
...
this.setState(stateToSet, () => {
if (this.props.parentOnBlur) {
this.props.parentOnBlur(this.state);
}
});
....
}

So here we want to execute 2 different callbacks depending on the event. If we fire onChange() we want to fire its parent's onChange if provided in the component props and so on. In short every type of setState() needs to have a separate useEffect(). How can this be managed with hooks without the "removed" callback. The only way I could think of, is to have additional if / else logic inside the useEffect() hook ?

[phryneas]

Exactly that example is why you wouldn't want that callback.
In your case, usually you want to directly call props.parentOnChange after calling setState, without waiting for setState to acutally happen. (so you wouldn't use useEffect as well!)
The reasoning for that is pretty simple: if props.parentOnChange also triggers a state change, those two will be batched together . But if you wait until after the first setState has completed, you might introduce a double-render and inbetween have inconsistent states.
Also, I can't think of many situations where you really would want to wait for setState to propagate before calling that parent callback - the parent has no access to the internal state of the child component anyways, so there'd be no way the child state is of any interest to the parent component.