Model React opaque element types soundly

[motiz88]

Alongside strings, stateless functional components and class components, React currently accepts a set of internal symbols for an element's type (and a few others wrapped in a { $$typeof: ... } object). The symbols themselves are all private; they form "opaque components" that are returned from various public APIs and serve to trigger certain intrinsic behaviours within the renderer.

In Flow, because of limitations in react_kit.ml, we instead model these as function and/or class components, which works in most ordinary cases, but is not technically correct - e.g. Flow will let you call or construct them, which will cause an error at runtime. It would be better if we could leverage opaque types, while keeping props checking and all the other nice things. (Architecturally - perhaps we can allow libdefs to declare these opaque types rather than having to build them directly into react_kit.ml?)

The following is a list of React features based on opaque component types and how they're currently modelled in Flow, if at all.

Stable features

• Fragment - modelled as a function
• StrictMode - modelled as a function in Add React.StrictMode #6078
• Context Provider - modelled as ComponentType
• Context Consumer - modelled as ComponentType
• Return value of forwardRef - modelled as ComponentType in Add definition for React.forwardRef() #6510

Unstable features

I'm including these for completeness, as they can be expected to officially land in future versions of React. There is no current implementation or PR for these in Flow.

• unstable_AsyncMode
• unstable_Profiler
• Placeholder

[jbrown215]

The machinery necessary for this will be going out in 0.89. This fixes Fragment, StrictMode and forwardRef. I will also take a look at Provider and Consumer.

[jbrown215]

This also fixes Provider and Consumer.

[TrySound]

I guess it's fixed with AbstractComponent.