TSX and React Context API broke on nightly

[pocesar]

TypeScript Version: 3.2.0-dev.20181017

Search Terms: react, tsx, jsx, construct, call signatures.

Code

import React from 'React'

const Context = React.createContext<{}>({});

const El = <Context.Provider>{() => null}</Context.Provider>

Expected behavior:

Works as in 3.1.3

Actual behavior:

Giving JSX element type 'Context.Provider' does not have any construct or call signatures.

[asvetliakov]

Another example with same error:

import React from "react";
declare const Comp: React.SFC | React.ComponentClass;
<Comp />

[weswigham]

Righto, with #27627 we removed the ability JSX tags had to attempt to resolve multiple call or construct signatures using the same expressions (and this was intentional because this is very unsafe, since we annotate types on those expressions during contextual checking). We need #7294 as a general solution to solve the problem for all kinds of calls (although JSX throws an extra wrench in that bucket by having methods of resolving both constructors and functions at the same time).

Right now a Provider (and a Consumer for that matter) claims to be a ComponentType - they should probably claim to one of either be a StatelessComponent or a ComponentClass (SFC is simpler and so would be my preference), not either or, honestly. Though in reality its neither.

[asvetliakov]

@weswigham

How to express HOC for both SFC and Component class now?

export function HOC(WrappedComponent: React.ComponentType) {
    // error
    <WrappedComponent />
}

declare function HOC1(WrappedComponent: React.SFC);
declare function HOC2(WrappedComponent: React.ComponentClass);


HOC1(A);
// NON-SFC are not accepted
HOC1(B);

// SFC are not accepted
HOC2(A)
HOC2(B);

Edit: Looks like adding overload signature works

[weswigham]

import React from "react";
declare const Comp: React.SFC | React.ComponentClass;
<Comp />

Yes, we explicitly removed the code that allowed that to function in #27627 as what that codepath was doing was unstable in the presence of contextually typed attributes (ie, function children or attributes with untyped parameters). We're looking into fixing #7294 in a more general, safer way as a replacement.

[weswigham]

(So yes, it's broken right now, yes, we know, and yes, we'd like to fix it, however the break was intentional to fix a mountain of other problems caused by the hackish way it was accomplished.)

[ulrichb]

@weswigham

I get the same error ("JSX element type 'React.Fragment' does not have any construct or call signatures") for the following code.

import * as React from "react";

const fragment = (
    <React.Fragment key={42}>
        <div>a</div>
        <div>b</div>
    </React.Fragment>
);

Does this mean that the declaration for React.Fragment has to change?

The current (Definitly Typed) declaration is as follows.

const Fragment: ComponentType;
type ComponentType<P = {}> = ComponentClass<P> | StatelessComponent<P>;

[brieb]

@ulrichb Yep, Fragment is defined in the same way as Provider and Consumer, using ComponentType. StrictMode would also need to be changed.

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/3ea5ad14c4b453916df64fbec2bf3530d15c9184/types/react/index.d.ts#L272