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?

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

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 tocreateRoot rapidly, it's far easier for us to ensure that certain components will work and then eventually move thatConcurrentMode boundary higher and higher up each tree until eventually they can be replaced with acreateRoot.

Is this something you'd considered?

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