I’ve been doing a lot of React in the past twelve months and have become reasonably comfortable with the component lifecycle and the async nature of thinking in React (especially when you combine it with the dynamic data from Meteor).
However (and I am not sure if this was how it was originally or not) I had been using setState with an object to update my state. I found the shallow copy mechanism also useful in other parts of my code (which is very easy to use with ES6 destructuring assignments instead of using Object.assign).
Now I discover that the RECOMMENDED way to use setState is with a function callback. This opens up a whole new world... [no - not the song from the Aladdin movie].
Given that setState is async (and can be batched) there didn’t appear to be a reliable way to sequence some other work (other than using componentDidUpdate/componentWillUpdate) that was based on changing the state. There are only certain places where you can update the state. But the callback approach solves that (especially when you want to get sequentially incrementing numbers or to do something else before the component updates). I am sure I even thought at one point: “The parameter to setState should be a function”.
On top of that, there is also a second callback that will called after your callback has been applied. While this is not recommended (over componentDidUpdate) it does provide another way to trigger other activity without directly polluting the component itself.
Both of these functions could be passed into the component as props - thereby completing isolating the state management from the component itself! [You’d really want to know what you were doing - but it is very powerful]
No practical examples in my own experience as yet but I’ll be keeping an eye open for where I might need to use it.  I know I have written code where I have delayed certain things that would depend on the state being updated (versus using componentDidUpdate).
Stay tuned.... if I find a good use-case, I’ll write it up.
