Add a PropTypes for React elementType (ie. MyComponent)

[eXon]

There is a missing prop type that is quite common for a lot of people: PropTypes.component. The PropTypes.element already exists to support <MyComponent myProp={<MyOtherComponent />} />. However, there is no way to easily type check: <MyComponent myProp={MyOtherComponent} />. Before React 16.3, we were getting away with PropTypes.func.

ForwardRef in 16.3

However, with new features since React 16.3, there is a new challenge: forward ref! forwardRef is generating a React component, but in a different form: it is an object! This is breaking the old way of using the PropTypes.func and making the type checking unreliable. To fix this, we need a more complex prop type:

MyComponent.propTypes = {
  myProp: PropTypes.oneOf([
    PropTypes.func,
    PropTypes.shape({
      $$typeof: PropTypes.symbol
    })
  ]).isRequired
};

The problem with this:

1. Now we're leaking an internal implementation of React
2. If you pass an element (<MyComponent />) instead of a component (MyComponent), it would not fail. An addition check on the $$typeof value has to be made and now the complexity is getting out of hand for a prop type that should be simple.

To fix this, I've added PropTypes.component that would fix this problem by checking the $$typeof and only allow components.

Higher-Order Component (HOC)

The reason why this prop type is so important to add is because of HOC. If you're using a library HOC, as soon as you add the decorator on your component using forwardRef (example react-cookie, see bendotcodes/cookies#172), your component is an object instead of a function and most libraries (example react-router) are using PropTypes.func to check if your passing a component. The typecheck wrongfully fails.

What should be a component?

First we need to support regular stateless and stateful component. The best way to do that is by checking if it's a function. I don't think we can do better here unfortunately because of stateless components.

Then, there is special cases created by React like the forward ref. Here are all the $$typeof we can check and which one should be a component or not:

• REACT_PROVIDER_TYPE: Yes

• REACT_CONTEXT_TYPE: Yes

• REACT_FORWARD_REF_TYPE: Yes

• REACT_ELEMENT_TYPE: No

• REACT_PORTAL_TYPE: No

• REACT_FRAGMENT_TYPE: No

• REACT_STRICT_MODE_TYPE: No

• REACT_PROFILER_TYPE: No

• REACT_ASYNC_MODE_TYPE: No

• REACT_PLACEHOLDER_TYPE`: No

Forward ref is the most obvious use-case, but the context provider/consumer are technically component created by React. I just don't think it would be used much in a prop though.

Remaining Concerns

Here are my main concerns with this PR:

Bumping React version to 16 in devDependencies

The tests were running on the old 15 version of React, I'm guessing to make sure we don't break the old version. However, to test forward ref and the context API, we need at least React 16.3. I've updated the version, but an alternative would be to have two different package with the different version. Is it worth it? Also, should we bump the version of prop-types to 16? There is no breaking change, but the tests would be running on that version unless we run the tests on both by adding a proxy package pointing to React 15.

Should we really call that new prop type component?

I think it's the best name, but in the previous code, the prop type element (and sometimes node) were referred as component. To me, a React component is MyComponent while a React element is <MyComponent />. Is it so for the community? Is the distinction clear enough?

EDIT: Been renamed elementType to follow is-react name.

Where I've added isValidComponent

Looking at the isValidElement code, I tried to stay consistent with where to put the code. However, I'm not sure this is 100% clean. I can refactor this if you think this is a problem, but I've tried to stay consistent with the current state of the code.

Should we have more validation?

We could add more validation. Is the component should be a specific one? Should the component have a specific set of prop type (not sure about the use cases)?

Documentation

If this is merged, we would need to update the React documentation with the new prop type. I can help with that once this is merged.

Fixes #223.

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[ljharb]

this seems like it would return a lot of false positives, but i don't know of a better way to cover SFCs. It seems like an early return true for class-based components, though, would be better. You may want to use the react-is package here, and check the various "is" methods contained within.

[eXon]

I agree, it was my first though but went for a first version before digging into this. If it's a function (not a class), it should accept it. If it's a class, we should check if it inherits React.Component or from React.createClass. Not sure if I can do this with enough reliability.

[ljharb]

these should be pulled from react-is and not hardcoded here.

[eXon]

I would have to add the react-is as a production dependency, are you open to that? I saw you were already hardcoding the element type. I wouldn't mind switching all of them.

[ljharb]

i'm not a collaborator on this repo, but personally yes, i am - it's minified heavily in production, and you could also wrap the require in a NODE_ENV check.

[eXon]

This is related to #200. Would probably fix the issue.

[ljharb]

this needs to be renamed also?

[eXon]

Turns out is-react have everything elementType needs. Even though we depend on the 16.5.0 version, I don't think it would have any problem to work on older versions including 15.

[taion]

BTW, we've had this implemented in prop-types-extra as elementType for a while. We've found it helpful to include an additional warning when the user accidentally passes in an element: https://github.com/react-bootstrap/prop-types-extra/blob/v1.1.0/src/elementType.js.

[eedrah]

Closed issue #223 in favor of this pull request.

[aldeed]

@ljharb Anything community can do to help get this merged and released? Code appears similar to working code that I had previously posted and to the prop-types-extra code mentioned, and your earlier comments appear to have been addressed. In general LGTM as far as fixing my #200 issue.

[ignatevdev]

Can we get some attention from the maintainers?

Without this PR we can't get rid of the PropTypes warnings from third-party packages, as they all rely on a component being either string, node or function.

[slorber]

Hi,

Not sure it's totally related but I'd like to do this:

tagName: PropTypes.oneOfType([PropTypes.string, PropTypes.element, React.Fragment]),

Any idea if this can be done today? it seems fragment is "included" into elementType but can we restrict to fragment?

[ljharb]

I don’t think that’s currently possible, no. File a new issue?

[Asday]

Missing from the docs.

https://reactjs.org/docs/typechecking-with-proptypes.html#proptypes

[ljharb]

@Asday the note at the top of that page tells you more or less to to ignore that page and go to the prop-types library, which does have it in the docs.

[Asday]

Dangit I'm trying to look at the page now and it's got DNS errors.

I wasn't aware the documentation had moved. :(