[m0meni]

AFAIK concurrent React breaks a lot of the currently existing ecosystem. For example, I think right now the current versions of redux and MobX don’t work with it. Granted, concurrent mode is not even close to out yet, but I’m curious what the migration path looks like.

[Klathmon]

I don't know the answer (or if there is a fully formed answer at this point), but I have heard the React team talk about this a bit.

Facebook internally has a MASSIVE number of components, and apparently a lot of them are using older APIs and older paradigms. Because React is ultimately by and for Facebook, they simply can't afford to make lare breaking changes, it's just not a realistic option. Everything they do has to have a good mostly-automatable path forward.

I don't know for sure how they will handle it, but I have a feeling it will be using the StrictMode stuff that they introduced a few versions ago. I'd wager they will have a way to enable concurrent react for a Component and the tree of children nodes, and will stick to the current implementation for everything that isn't compatible. This will let you enable the new features in only parts of your app that need it, or slowly migrate over to it and opt-in over time. And I believe I read somewhere that if a component runs happily in StrictMode that it's already concurrent-react ready (but please don't take that as fact!).

[acemarke]

Yeah, ConcurrentMode is going to be entirely opt-in, per subtree, as a component: `<ConcurrentMode>`. And yes, that's the point of `<StrictMode>`: a form of runtime linting for known patterns that will cause problems in CM.