Opt into unsafe lifecycle warnings without async tree

[bvaughn]

Opts a subtree into the same warnings as AsyncComponent does, but does not actually enable async rendering. This same mechanism could be extended for similar warnings in the future (eg compiler, React Fabric).

Following precedent, this component is exposed via React.StrictMode. It is used like a Fragment to wrap an element:

const {StrictMode} = React;

<StrictMode>
  {/* Subtree here */}
</StrictMode>

This branch builds on top of #12060.

[sebmarkbage]

Duplication is not a good enough reason to introduce an abstraction. Even if file size decreased it can also introduce overhead through other mechanism which is why Prepack tend to work well. This also introduces extra temporary object allocations during initialization. And at the end of the day, I now have to go figure out what configurePrototype actually means instead of just seeing exactly what it does inline in the code when I'm reading it. A lot of the original criticism and the existing problems we have is because of such indirection. Especially when we add more stuff to it. So not sure this is a net positive.

I think we should stop thinking about these changes as enabling async as much as just being future compatible. E.g. a similar opt-in mechanism might be required for the compiler and it'll also require the same deprecations. We might also add more deprecations that only help compilers. Fabric as well. It would be good to have a single story around this instead of having to opt-in for each one.

Maybe we can rename it to something like <EnableFutureCompatibilityChecks /> or something? I don't know.

[sebmarkbage]

Are we sure this matters these days in any significant way? Maybe we can just kill this.

[sebmarkbage]

@acdlite Originally we thought that we needed to be able to inherit AsyncComponent instead of wrapping, because at the top level it is tricky since it affects the return value of render. However, if you're upgrading at the top level, you probably want to use the createRoot API instead. Do we still think that we want the inheritance mechanism or should we switch to what context and fragment do?

[bvaughn]

Duplication is not a good enough reason to introduce an abstraction.

The code felt crufty and repetitive before, so I proposed a change. I'll revert it.

Maybe we can rename it to something like <EnableFutureCompatibilityChecks /> or something? I don't know.

Interesting. I like this suggestion. Not sure about that name but I like the suggestion.

[bvaughn]

I went ahead and made the suggested changes, using EnableFutureCompatibilityChecks for now. I posted a poll internally to see if we can't come up with a better name though.

[gaearon]

To give some background on the abstraction thing, the code feeling crufty/duplicated is how we ended up with a lot of things in the Stack implementation (like "Transactions") that ended up being hard to work with. So these days we try to err on the side of making removal of the code easy rather than making it feel dry.

You know why the abstraction was added and thus know when to remove it. But other people often don’t, and as time goes everybody is afraid to rip out each other’s abstractions, and we end up with overabstracted code that seems to be necessary but no one’s really sure. Hope this makes sense 😛

[bvaughn]

Sure, it makes sense. I didn't feel strongly about the change anyway. I mentioned in the initial PR description that I would be happy to revert it if there were any concerns, for this reason ^

[bvaughn]

Based on discussion above and in person (during lunch) I've updated this PR as follows:

• The new component type is named StrictMode (rather than anything to do with async).
• The new internal context flag is also named StrictMode.
• Async subtrees are also StrictMode subtrees and all of the previous async warning checks are now based on this flag instead.
• The ReactDebugAsyncWarnings helper has been renamed ReactStrictModeWarnings to avoid confusion.
• A warning message has been updated with a new fb.me link, https://fb.me/react-strict-mode-warnings

[sebmarkbage]

What did you think of @tomocchino's ReactDOM.renderStrict(...) proposal to opt in a whole tree?

That would eliminate the need for base class based opt in class Foo extends StrictMode which seems weird to extend a "mode".