-
Notifications
You must be signed in to change notification settings - Fork 46.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Concurrency / time-slicing by default #21662
Comments
For updates caused by discrete user interactions like click/typing, it won’t ever be the default because those must execute sequentially and usually require immediate feedback. For updates originating outside of such events — for example, from a fetch callback — it’s possible that we’ll make time slicing default in a future major release (not in 18 but some future one), or that we would warn if you don’t use startTransition. This is still up in the air and very much depends on the state of the ecosystem compatibility with concurrency in the future. We definitely would not change the behavior during the React 18.x release line because that would’ve been a breaking change. For now it’s a bit early to decide how future major versions should work. |
Hello. I'm testing React 18 features and I would like to test the time slicing feature. I've seen that this PR adds an option to createRoot for using time slicing. The problem I'm having is that this options seems to be behind a flag called Thanks! |
The way you opt into time slicing in React 18 is per-update. You do that by wrapping that update into Explanation: reactwg/react-18#41 |
@gaearon makes sense. Thank you for the explanation. Yeah, making a distinction between updates that require immediate feedback versus ones that don't and thus are eligible for time-slicing is something that requires an explicit API such as startTransition I suppose. Was wondering if it would also be generally beneficial on first render, but I guess the Suspense boundaries take care of that per subtree anyway? Thanks for the awesome work React team! |
Other question, does the implementation of the scheduler still make use of requestIdleCallback? I believe WebKit is the only holdout for that one. |
Do you mean first render of the app, or first render of the component? For the entire app, I think maybe wrapping For an individual mounting component, you can wrap the state update that causes it to mount. We also have a separate experimental feature that lets |
No, it fired too late and we'd waste CPU time. It's really important for our use case that we utilize CPU to full extent rather than only after some idle period. So instead we rewrote to have our own loop that yields every 5ms. |
Will concurrency / time-slicing ever become the default behavior? Or will it always require a startTransition block to opt-in?
If it will become the default at some point, will that become part of the React 18 timeline or a later major release?
The text was updated successfully, but these errors were encountered: