https://codesandbox.io/s/07293kpnn
The UI is nearly as responsive as their improved example.
I'm not a React expert, but I do know that browsers defer timeouts until they have time to process them. This can be used to take heavy-hitting functions out of events that block UI interactions. It can also be used for self-throttling recursive IIFEs.
If we keep that in (https://codesandbox.io/s/93yv4j129p), my previous comment holds true: https://news.ycombinator.com/item?id=19332577
Here is by the way a version with all artificial slowness removed: https://codesandbox.io/s/9859x0wm9p You can see that this example does not need any optimizations out of the box. This is why I added the slowness to simulate a more complex app.
This is something setTimeout is incapable of helping with. Because even if you delay the work, at some point it’s still gonna block.
In either case this example is very simplified and doesn’t illustrate the subtle difference as much. We’ll prepare our own examples when the features are stable.
Can you interrupt an arbitrary user-written function that's called inside the rendering stack?
As a user of the framework, you don't need to care about this though. So your mental model can be that of an interruptable function.
[1]: https://overreacted.io/react-as-a-ui-runtime/#lazy-evaluatio...
https://twitter.com/acemarke/status/1103373148169347072
There's a lot of nuance involved here. Moving some behavior outside the current tick may speed certain things up. Keeping multiple React updates in the same tick may _also_ speed other things up. It depends on what work is being done in these additional callbacks, and where/when they're being executed.
In this specific case: `this.props.onChange()` calls the parent component's `setState()`. That should ideally be kept in the same tick as `this.setState()`, so they can be batched.
`sendAnalyticsPing()` does _not_ cause a React update. That should indeed be moved out to a separate tick, so that it doesn't slow down this update.