setState(), shouldComponentUpdate(), And render() Timing In ReactJS

setState(), shouldComponentUpdate() & render() timing in #ReactJS:

  • 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