Remove <React.unstable_ConcurrentMode /> element type by acdlite · Pull Request #15532 · facebook/react (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation5 Commits1 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

acdlite

We decided to remove this because we're not convinced it's practical to opt a particular subtree into Concurrent Mode without opting in the entire root. The recommendation is to use createRoot instead.

@NE-SmallTown

Could we preserve this(concurrent mode) and just allow it be used in root? By the way, could you share more info about why it's impossible to be used in a particular subtree without opting in the entire root?

sebmarkbage

@acdlite

@NE-SmallTown It's not impossible, but it creates weird edge cases that we'd prefer not to support, given that we haven't found a compelling enough use case for it.

@acdlite

Use createSyncRoot instead.

This was referenced

Aug 17, 2019

This was referenced

Aug 19, 2019

@VinSpee

we're not convinced it's practical to opt a particular subtree into Concurrent Mode without opting in the entire root

Hi! at @tedconf we use many roots, and are slowly migrating things to be concurrent-safe. For us, it's not practical to upgrade every single root to createRoot rapidly, it's far easier for us to ensure that certain components will work and then eventually move that ConcurrentMode boundary higher and higher up each tree until eventually they can be replaced with a createRoot.

Is this something you'd considered?

@sebmarkbage

@VinSpee, yea that use case was the original purpose but it turns out that the semantics doesn’t quite make sense in the mixed world. We can’t guarantee exactly how the changes in the top of the root flows into the subtree. Similarly if something suspends inside the subtree, that can trigger a boundary in the outside. So it adds a lot of complexity that you are probably better equipped to handle in user space.

However you can still add StrictMode in subtrees to get warnings and some dev mode things that get your ready for concurrent mode.

There is also the createSyncRoot api that has some of the same semantics as concurrent mode.

Then once you have one root that is complete you can just upgrade that one.

This was referenced

Aug 27, 2019

This was referenced

Mar 10, 2020

This was referenced

Mar 18, 2020