I think it neglects Dan's original point. Say you're doing a search input that filters a list of elements using fuzzy matching. No amount of optimization in your components or the framework is going to make the fuzzy string matching library you use work faster. Faster renders might make more room for the main thread to update, but fundamentally the problem persists. Concurrent React would allow you to type while the fuzzy matching happens asynchronously.
This is different than the demo shown. The demo with the charts is very render heavy. It's an unrealistic experience (and in my opinion, it is regretful that it was used to show the power of async rendering). In any real application, if you're rerendering thousands of nodes on every key press when their component instances are not changing input/state, something is very wrong. A fuzzy string matching filter is a much better example of this, since the visibility of each item is dependent on the state of the text input.
Sure, not all items in your list will update simultaneously. But are they really all visible on screen? Do they really all do need to be updating instantly? The overhead of the framework is almost certainly negligible here either way. But the scheduling that takes place is going to be critical, because that's what will directly affect how the app's performance is perceived by the user.
> Say you're doing a search input that filters a list of elements using fuzzy matching. No amount of optimization in your components or the framework is going to make the fuzzy string matching library you use work faster.
> Concurrent React would allow you to type while the fuzzy matching happens asynchronously.
Are you sure that is the case?
From what i gathered about concurrent React and Fiber is that it can split the rendering of multiple components into different time slices, and also give more priority to certain events, so that some re-renders are kept smooth and responsive (the input typing on the demo), while others can be split into multiple frames and delayed a bit (the update on the carts).
But all React can do is to split up multiple render() calls (or function component calls) into different time slices. It cannot "slice" a single render() call any further. So, if there's an expensive synchronous computation inside that render(), like the hypothetical `fuzzySearch(query)`, that computation will block the main thread no matter what, and the application will be unresponsive until that computation finishes.
There's no going around that if the fuzzy match function is synchronous. That function would have to be changed not to block the main thread. E.g., it could have a timeout so it doesn't take longer than, say, 10ms, and return a partial list of results on that case. Or be a generator, so you can consume its matches one by one and split that work into different frames. Or you could move that computation to a webworker, thus making it effectively asynchronous, and avoiding blocking the main thread.
I don't think there's much React, or any framework, can magically do in this case to make a synchronous expensive operation not block the app. But maybe i'm completely wrong and that's exactly what concurrent React does; or maybe i misunderstood your scenario entirely :)
Instead of results.filter(fuzzySearch(query).match) at the list level, you'd simply map all results and do the fuzzy matching within each result's render function (returning null if it doesn't match).
In that case, instead of fuzzy matching each result in one render, it's spread over many smaller renders. When those get executed is much less important and can be scheduled for idle time by the browser.
This is different than the demo shown. The demo with the charts is very render heavy. It's an unrealistic experience (and in my opinion, it is regretful that it was used to show the power of async rendering). In any real application, if you're rerendering thousands of nodes on every key press when their component instances are not changing input/state, something is very wrong. A fuzzy string matching filter is a much better example of this, since the visibility of each item is dependent on the state of the text input.
Sure, not all items in your list will update simultaneously. But are they really all visible on screen? Do they really all do need to be updating instantly? The overhead of the framework is almost certainly negligible here either way. But the scheduling that takes place is going to be critical, because that's what will directly affect how the app's performance is perceived by the user.