Is being StrictMode compliant required to use concurrent features?

[liuyenwei]

In #4 (reply in thread), it is mentioned that

you don't need to be StrictMode compliant to use concurrent features

In the past, my assumption was that we would have to be StrictMode compliant in order to use concurrent features (mostly based on a combination of reading these two: https://reactjs.org/docs/strict-mode.html and https://reactjs.org/docs/concurrent-mode-adoption.html#feature-comparison).

I was wondering if we could get more clarity around this point and, specifically, which deprecations/warnings are important for adopting concurrent features. From a migration standpoint, I think this would be helpful to understand so developers can prioritize work to fix StrictMode violations (i.e. do we need to remove 100% of findDOMNode usages before we can use concurrent feature ____)

[gaearon]

Thanks for asking! It’s a bit nuanced.

• You don’t have to enable StrictMode to use the concurrent features. It’s a tool to find mistakes. But the tool itself is optional.
• Strict Mode checks for a bunch of stuff. Some of this is relevant for concurrency and some isn’t.
  • Strict Mode warns about some deprecations. They are technically unrelated to concurrency, at least at this moment. So string refs, findDOMNode and legacy context are problems but mostly because we will be removing them altogether at some point. Not because of new features per se. (That said, we also don’t guarantee that all new features will forever be compatible with these deprecated APIs either. We just aren’t aware of any current incompatibilities.)
  • Strict Mode also has some DEV-only behavior that helps find accidental side effects. That includes double rendering in development. That double rendering itself is not a requirement for using concurrent features. It’s a development tool to find mistakes. But mistakes it surfaces (mutations and side effects during render) can in theory also cause bugs when using concurrent features.

In practice, even when these bugs may happen, they not necessarily will. As you can imagine few components are “perfect” and in practice even in completely synchronous React there’s a lot of potential for mistakes in components. What we’ve found in practice is that mistakes related to concurrency don’t come up more often than mistakes in product code in general. We haven’t seen any significant increase in bugs after fixing a few libraries and infrastructure-level code. The product code, even when not written with StrictMode, mostly “just works”. In fact we’ve had an embarrassing mishap where double rendering was accidentally off for FB engineers for many months, so it was as if they wrote code without Strict Mode. But it mostly worked fine too.

To summarize:

1. Deprecations (like findDOMNode and legacy context) aren’t directly related to new features but using them will at some point prevent you from upgrades.
2. Strict Mode compatibility isn’t “required” for using new features and in many cases your product code will likely work anyway. For library code being compatible is more important because each mistake is magnified across every component using the library.
3. However, Strict Mode does offer an extra level of assurance.

[liuyenwei]

This helps a lot, thank you!