- All calls to setState() have to be processed immediately since ReactJS has no way of knowing when it would be safe to dequeue said state changes.
- When a call to setState() is made from within something like a setTimeout() callback, ReactJS doesn’t have hooks into the surrounding context.
- ReactJS understands the context and can safely enqueue the state changes and then flush them after the event-delegation is complete.
- Once the state is changed, ReactJS has to reconcile the change-in-state with the virtual DOM (Document Object Model) and, subsequently, with the rendered DOM.
- If the change in state cannot be queued and flushed asynchronously, it turns out, neither can any of the post-change events.
Read the full article, click here.
@ReactiveConf: “setState(), shouldComponentUpdate() & render() timing in #ReactJS:”
Ben Nadel looks at how often the shouldComponentUpdate() and render() methods are called, in ReactJS, based on calls to setState(); and, how that varies from context to context.
setState(), shouldComponentUpdate(), And render() Timing In ReactJS