Change .forceUpdate() to participate in the update queue

[developit]

This changes forceUpdate so that it's no longer inherently synchronous, instead pushing updates into the same queue currently used for state.

This means the following produces a single render pass:

class Demo extends Component {
  componentDidMount() {
    this.setState({ a:'b' });
    this.forceUpdate(() => console.log('updated'));
    this.setState({ a: 'c' });
  }
  shouldComponentUpdate() {
    return false;
  }
}

// A single render is triggered, bypassing shouldComponentUpdate, with `{a:'c'}` as state.

I left a commented-out possible tweak that would still allow standalone forceUpdate() to be synchronous when nothing else is in the queue, but I'm not sure that's desirable.

[robertknight]

Out of interest, do you (or anyone else) know how this behavior compares to React in its various rendering modes (normal, batched, concurrent etc.)?

[marvinhagemeister]

I haven't compared the various render modes of React specifically, but I can confirm that they schedule forceUpdate in some sort of queue and process all updates in the expected order. My guess is that this should be consistent across render modes and that those only change how the queue is processed. I'm leaning a bit out of the window here though

[developit]

@robertknight @marvinhagemeister yes I think this is somewhat analogous to batched mode. Certainly in name, the change here enables batching of forceUpdate, meaning the only way to produce a non-batched update is now a top-level render() call for the tree. The nice part there is that any components re-rendered during that render() call will be unmarked as dirty, and their existing forceUpdate()/setState() enqueued re-render will be ignored when triggered. Any portions of the tree that don't get updated from the top-level render will still be updated when the batched changes are scheduled for rendering.

[coveralls]

Coverage increased (+0.001%) to 99.883% when pulling 5c4168a on forceupdate-queue-participation into 9eba4e0 on master.

[JoviDeCroock]

This is looking great all failing tests should be resolved by rerender addition in the tests. analogue to #1892 (might be able to cherry pick)

[marvinhagemeister]

@developit Awesome, also +1 on the additional tree-shaking benefits :)

Now we just need to pass the failing tests and then we're good to go 🎉

[marvinhagemeister]

@JoviDeCroock Good catch! I went ahead and added all missing rerender() calls. This fixed every failing test except one 🎉

There componentWillReceiveProps was erroneously called on setState due to forgetting to set the force flag. Pushed a commit for that and the CI should be green now 👍

[marvinhagemeister]

Super awesome! This makes it a lot easier for the devtools to measure commits and other things. Love it 💯 👍

[JoviDeCroock]

I think it'd be good to change the setter in useReducer to forceUpdate now instead of setState({}) might save some bytes too

[marvinhagemeister]

@JoviDeCroock just checked: Using forceUpdate instead of setState({}) in our hooks code would make it larger by +2 B