TSX behaves differently than plain TS when component returns null

[donaldpipowitch]

TypeScript Version: 2.1.0-dev.20160829

With @types/react@0.14.41 and "strictNullChecks": true.

Code

// with @types/react@0.14.41
// SFC returns null: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/11912
import * as React from 'react';

const CustomComponent = (props: { flag: boolean }) => props.flag ? React.createElement('div') : null;
const UseComponent = () => React.createElement(CustomComponent);  // works
const UseComponent2 = () => <CustomComponent />;  // throws

Expected behavior:

TSX behaves like plain TS.

Actual behavior:

TSX throws

[ts] JSX element type 'DOMElement<{}, Element> | null' is not a constructor function for JSX elements.
       Type 'null' is not assignable to type 'ElementClass'.

[RyanCavanaugh]

@yuit we'll need to update react.d.ts and make sure that Element is a type alias for (what the current element is) | null and that our JSX resolver properly checks against type aliases

[JakeGinnivan]

When this is fixed the case for returning strings from stateless components should also be fixed.

const Link: React.SFC<{ text: string, link?: string }> = ({ text, link }) => {
  if (!link) return text

  return <a href={link}>{text}</a>
}

[yuit]

@JakeGinnivan could you give a pointer to the documentation about return strings from SFC, I couldn't find it online. Thanks

[JakeGinnivan]

@yuit I can't find anything actually, seems that usage was wrong.

[olmobrutall]

Hi guys,

The change in react.d.ts has generated some breaking changes and we're not sure what's the way forward:

• What is the type of <MyComponent />? before was React.ReactElement<any>, but now null have to be there. Why? If MyComponent is a SFC returning null, the react component should still be there but have no intrinsic elements inside, right? Why are SFC special?

• What type should be used now to represent a mandatory React.ReactElement<any>? And a mandatory React.ReactChild?

The issue is here:
DefinitelyTyped/DefinitelyTyped#14284

[DanielRosenwasser]

We're going to be taking a look into fixing this up.