Concurrency / time-slicing by default

[rybon]

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?

[gaearon]

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.

[tlgimenes]

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 allowConcurrentByDefault that is not enabled for @experimental or @alpha releases of React. Is it possible to enable this feature flag for @experimental releases?

Thanks!

[gaearon]

The way you opt into time slicing in React 18 is per-update. You do that by wrapping that update into startTransition.

Explanation: reactwg/react-18#41
Demo: https://github.com/facebook/react/tree/master/fixtures/concurrent/time-slicing

[rybon]

@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!

[rybon]

Other question, does the implementation of the scheduler still make use of requestIdleCallback? I believe WebKit is the only holdout for that one.

[gaearon]

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?

Do you mean first render of the app, or first render of the component?

For the entire app, I think maybe wrapping root.render into startTransition could work. I haven't tried.

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 <Suspense> boundaries "defer" expensive CPU trees that aren't network-bound. (By default, Suspense only defers network-bound trees.) See #19936 for details.

[gaearon]

Other question, does the implementation of the scheduler still make use of requestIdleCallback?

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.