`typeof React.forwardRef(...)` is not a 'function', breaking third-party libs

[jamesreggio]

Do you want to request a feature or report a bug?

Bug, possibly

What is the current behavior?

The new React.forwardRef feature returns an object, not a function.

To this point, the typeof both stateless components and class components was 'function'.

React does not expose a utility to check whether a given value is valid to be passed to React.createElement. As a result, third-party library authors who wish to pre-validate a component type will commonly use typeof Component === 'function' to test whether the type is valid. The return value of forwardRef, despite being a valid component type, will fail this naive test. Library authors do this in order to provide better errors than would otherwise be provided by React if an invalid component type was passed in.

In a perfect world, the fault would fall squarely on the third-party library developers for using an imprecise check, but those developers could rightfully point out that React has given them little ability to be precise in these pre-emptive checks.

This is one of those "don't break the internet" bugs. This is a bug where third-party developers have taken reasonable-yet-illegal dependencies on React internals in order to provide a better experience for their users. If it's not too difficult, it may be a good idea to chane forwardRef to return a 'function', instead of an object.

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

React 16.3.0-alpha.3

[jamesreggio]

cc: @bvaughn, who implemented the forwardRef API in #12346.

The forwardRef API is described in this RFC: reactjs/rfcs#30

Finally, I encountered this issue when using React 16.3 with Next.js 5. See vercel/next.js#4055.

[gaearon]

React does not expose a utility to check whether a given value is valid to be passed to React.createElement

I don’t think we’re opposed to exposing a utility like this. We’re already releasing a package called react-is with some brand checking utilities along with 16.3, and I think we could add something like isValidElementType to it.

it may be a good idea to change forwardRef to return a 'function', instead of an object.

Then we’d have to look for a “special” field on every single function/class pass to React. I don’t think we’d want to go with that strategy since it introduces an extra cost for the majority of cases.

Ultimately I don’t think this problem is a blocker. It’s unfortunate, but React widening supported types is not a semver major change. If as a library author you choose to depend on the fact that React only supports defining components as classes or functions (and not, e.g., with objects), you are kind of committing to closely tracking what exactly it is that React supports. Of course a better solution would be to have a way to check it that’s maintained by us—and as I said, I think we’re open to providing that.

[gaearon]

This is one of those "don't break the internet" bugs.

As an aside, I’d prefer if we reserved this terminology for its original meaning: “ship something that breaks existing websites without any direct action on their behalf”. For example, Chrome’s “interventions”, Array.prototype.contains, etc.

Using this phrase to refer to a change where you opt in (by bumping the version of React, and later bumping some library to a new major—after all, it is now 16.3+—relying on forwardRef in public API) doesn’t seem entirely fair to me. It makes “break the internet” sound cheaper and more commonplace than it is.

[bvaughn]

We will be releasing the package Dan mentioned (react-is) along with 16.3. It exposes a function called isForwardRef, which could be used here. Although this function expects React elements (the return type of React.createElement) rather than a naked Component type, as the next.js validation check seems to be expecting.

Put another way:

const { isForwardRef } = require("react-is");
isForwardRef(React.createElement(Component)); // true
isForwardRef(<Component />); // true
isForwardRef(Component); // false

[jamesreggio]

We’re already releasing a package called react-is with some brand checking utilities along with 16.3, and I think we could add something like isValidElementType to it.

That sounds like the perfect solution. I wasn't aware of the creation of react-is, but it's a great idea!

As an aside, I’d prefer if we reserved this terminology for its original meaning.

Sure thing — sorry for the hyperbole. What I meant to express is that React is fully within its rights to add the forwardRef behavior in a minor change, but it may cause consternation amongst those who have taken 'illegal', yet reasonable, dependencies upon React internals.

---

Personally, I don't have a horse in this race. I just wanted to raise a problem I witnessed in the wild when using a new API whose design I considered during the RFC process, and suggest a solution or two.

[jamesreggio]

@bvaughn

Although this function expects React elements (the return type of React.createElement) rather than a naked Component type, as the next.js validation check seems to be expecting.

Checking the type after element instantiation seems like a fairly awkward developer experience. It's unintuitive to me because I would expect React to throw in the createElement() call if it received an invalid element type (even though, as of today, it appears that that check is deferred until the renderer begins mounting the element).

I realize that HOCs are going out of style right now, but there's compelling value to being able to check at HOC instantiation time that the component you're wrapping in the HOC is a valid component type. In fact, you'll see these checks for typeof Component === 'function' in some very popular libraries today, including Redux, React Native, and styled-components.

It's fine if you don't want to change how forwardRef is implemented, but I think it would be a good idea to have an isValidElementType in react-is before these breakages start rolling in.

[gaearon]

It's unintuitive to me because I would expect React to throw in the createElement() call if it received an invalid element type (even though, as of today, it appears that that check is deferred until the renderer begins mounting the element).

It intentionally doesn’t throw so that we can easily inline this function or replace it with a compiler output.

there's compelling value to being able to check at HOC instantiation time that the component you're wrapping in the HOC is a valid component type

I agree this is useful to HOCs.

[bvaughn]

Fair enough. I was just pointing out a difference between what Next is doing and how react-is works.

[jamesreggio]

Cool — I'll open a PR to add a element type validity check to react-is.

[jamesreggio]

I've opened a PR here: #12483

[bvaughn]

This new method has been added to react-is and will go out with the upcoming release. Thanks!