Update April 2022: With the update to React 18, a lot of those problems have been fixed. See this pull request for more details

I currently work with a couple of newcomers to React and teach them both TypeScript and React to create apps. It’s fun, and for me who’s been using that for a while now, it’s a great way of seeing this piece of tech through fresh eyes.

It’s also great to see that some of them use React in a way you’d never envisioned it. What’s not so great is if you encounter situations where React throws an error (and possibly crashes your app), where TypeScript doesn’t even flinch. One of these situations happened recently, and I fear there won’t be an easy fix to it.

The Problem #

Consider the following component. It’s a card, it takes a title and renders arbitrary children. I use my own WithChildren helper type (see React patterns), but the same is true if you use FC from the provisioned @types/react package.

type WithChildren<T = {}> = T & { children?: React.ReactNode };
type CardProps = WithChildren<{
  title: string;
}>;
function Card(props: CardProps) {
  return (
    <div className="card">
      <h2>{props.title}</h2>
      {props.children}
    </div>
  );
};

So far, so good. Now let’s use this component with some React nodes:

export default function App() {
  return (
    <div className="App">
      <Card title="Yo!">
        <p>Whats up</p>
      </Card>
    </div>
  );
}

Compiles. Renders! Great. Now let’s use it with an arbitrary, random object:

export default function App() {
  const randomObject = {};
  return (
    <div className="App">
      <Card title="Yo!">{randomObject}</Card>
    </div>
  );
}

This compiles as well, TypeScript doesn’t throw an error at all. But this is what you get from your browser:

Error
Objects are not valid as a React child (found: object with keys {}). 
If you meant to render a collection of children, use an array instead.

Oh no! TypeScript’s worldview is different from what we actually get from the library. This is bad. This is really bad. That’s situations TypeScript should check. So what’s happening?

The culprit #

There’s one line in the React types from Definitely Typed that disables type checking for children almost entirely. It’s currently on line 236, and looks like that:

interface ReactNodeArray extends Array<ReactNode> {}
type ReactFragment = {} | ReactNodeArray;
type ReactNode = ReactChild | ReactFragment | ReactPortal | boolean | null | undefined;

With the definition of ReactFragment to allow {}, we basically allow passing any object whatsoever (anything but null or undefined, but just look at the next line!). Since TypeScript is structurally typed, you can pass in everything that is a subtype of the empty object. Which in JavaScript, is everything!

The problem is: This is not a new change, it has been around for almost forever. It was introduced in March 2015, and nobody knows why. We also don’t know if the semantics back then would’ve been different.

Many folks pointed this out (see here, here, here, and here), and some folks tried to fix it.

But since it’s been around for 6+ years, this little change breaks a ton of packages directly connect to the React types. This is a huge change that is really tough to handle! So honestly, I’m not sure if we reasonably can update this line. Even worse: All those packages have the wrong tests and types. I don’t know what to think of that.

What can we do about it #

But we can always define our children types on our own. If you use WithChildren, it becomes even easier. Let’s create our own ReactNode:

import type { ReactChild, ReactPortal, ReactNodeArray } from "react";
type ReactNode =
  | ReactChild
  | ReactNodeArray
  | ReadonlyArray<ReactNode>
  | ReactPortal
  | boolean
  | null
  | undefined;
type WithChildren<T = {}> = T & { children?: ReactNode };
type CardProps = WithChildren<{
  title: string;
}>;

With that, we get the errors we want:

export default function App() {
  const randomObject = {};
  return (
    <div className="App">
      <Card title="Yo!">{randomObject}</Card>{/* 💥 BOOM! */}
    </div>
  );
}

And TypeScript is in tune with the real world again.

This is especially useful if you provide a couple of components to others! The moment e.g. some back-end data changes from being a simple string to a complex object, you spot all the problems in your codebase at once, and not through crashes in your application at runtime.

Caveats #

This works great if you are in your own codebase. The moment you need to combine your safe components with other components that e.g. use React.ReactNode or FC<T>, you might run into errors again, because the types won’t match. I haven’t encountered this but never say never.

Bottom line #

I keep asking myself if this little issue is really a problem as I myself have worked fine for years without knowing that ReactNode can basically be everything in TypeScript. Newcomers might be a bit more worried about their software not behaving as the types suggest. How can we fix that? I’m open for ideas.

Also hat tip to Dan for being the best post-release tech editor you can wish for 😉

Related Articles