3 ms·

> 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 t

> 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 :)

bastawhiz 7y ago
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.

bastawhiz 7y ago

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.