Detect "Functions are not valid as a React child." errors

[donaldpipowitch]

Search Terms

• "Functions are not valid as a React child."
• "Functions are not valid as a JSX child."

Suggestion

In React it is not possible to return a function as a React child. It would be nice if TypeScript could catch this type error.

Use Cases

Sometimes you want to use a function inside an JSX expression, but if you forget to call it, it will throw on runtime.

Examples

See https://codesandbox.io/s/n3k4ooq3jj:

import * as React from "react";
import { render } from "react-dom";

const helloWorld = () => "Hello World!";

const App = () => <p>{helloWorld}</p>;
                            // ^---- should catch "Functions are not valid as a React child."
                            // ^---- {helloWorld()} would be correct

render(<App />, document.getElementById("root"));

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript / JavaScript code ❓ It could break builds for invalid code, so... 🤷‍♀️
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. new expression-level syntax)

[RyanCavanaugh]

In React it is not possible to return a function as a React child.

We don't know what any given component does with its children; this is only known to be true for the built-in tags.

Presumably all we have to do is add a line to the react .d.ts that defines children of the intrinsic elements as

{
   (...args: any[])?: "Functions cannot be rendered";
}

and this should just work

[weswigham]

This is only allowed because ReactNode is poorly defined:

type ReactFragment = {} | ReactNodeArray;
type ReactNode = ReactChild | ReactFragment | ReactPortal | string | number | boolean | null | undefined;

Since ReactFragment contains {}, ReactNode is effectively {} | null | undefined which is effectively unknown or the top type, which can have anything assigned to it.

That {} should probably be object - althourgh functions are still objects, so it may not help much 😄 I would still question why {} is considered a valid fragment type, however!

[weswigham]

Yeeeeeah, I'm thinking that ReactFragment shouldn't contain {} at all - nowhere should that be required and it's a blanket licence to allow any type as a react child. (Plus, we typecheck fragments as type JSX.Element right now anyway)

[weswigham]

Looks like the React 0.13 .d.ts introduced this defect (DefinitelyTyped/DefinitelyTyped#3813) in the types. 😦 There's no comment on why, so I imagine it was a workaround for something unexplained? It's probably safe to remove?

[typescript-bot]

This issue has been marked as external or unactionable and has seen no activity in the last day. It has been closed for automatic house-keeping purposes.

[domdomegg]

Linking some more relevant issues together:

DefinitelyTyped/DefinitelyTyped#37596
DefinitelyTyped/DefinitelyTyped#35622
DefinitelyTyped/DefinitelyTyped#49705
DefinitelyTyped/DefinitelyTyped#29307