React: Unhelpful propTypes warning: Invalid prop `0` supplied to `Component`

[gaearon]

I use this pattern often:

/** @jsx React.DOM */

var Hello = React.createClass({
    propTypes: {
        modifiers: React.PropTypes.arrayOf(
            React.PropTypes.oneOf(['large', 'colored', 'fill'])
        )
    },
    render: function() {
        return <div>Hello {this.props.name}</div>;
    }
});

It's useful for flags that change too often and go straight to CSS without imposing any logic onto the component.

Say I pass an unsupported modifier:

React.renderComponent(<Hello name="World" modifiers={['other']} />, document.body);

React spits out an unhelpful warning:

Warning: Invalid prop `0` supplied to `Hello`, expected one of ["fill","colored","large"].

It's unhelpful because I have no idea what string 0 index corresponds to until I look it up in the code. It would save me a lot of time and hassle to see the actual array value that failed the check.

It there any reason why we don't show the value? Is it because it may not be serializable? Any workarounds?

[syranide]

Invalid prop `0` ...

Seems straight up wrong to me as the prop name is actually modifier, so probably in need of a proper error message and I don't see why a (truncated) value couldn't be shown.

[petehunt]

haha, i have a pending change for this internally already :)

[zpao]

Yo @petehunt where's this change?

[chenglou]

I left some comments on that diff but @petehunt's too busy all the time! =)

[sophiebits]

yeah, @petehunt where's this change? :)

[chenglou]

createEnumTypeChecker (and others) uses the format props[propName] to get the prop value. So createArrayOfTypeChecker has no choice but to pass the index as the prop name. I think the correct way to do this is to pass the prop value explicitly. I think I might have a hack to make this work nicely though. Forgot what pete's PR looked like

[brigand]

@chenglou any way we could have the index and name? Not a huge deal, but it does help narrow down the search space when working with inconsistent apis.

[chenglou]

@brigand possible but that might require an API change? I'm not sure whether it's worth it at this point

[mouthy75ks]

Leave a commentits worth it

[brigand]

@chenglou probably not, nevermind.

[jimfb]

Looks like this might have been fixed in https://github.com/facebook/react/pull/3737

Either way, we aren't actively working on the proptypes feature anymore (everything is moving to static analysis tools like Flow), so proptypes are on their way out. I'm not sure if we'd accept a PR, but I don't think this is something we'd actively develop internally at this point.

[jesstelford]

@jimfb Do you have an example of how you would use Flow to define the types for props? I can't quite connect the dots of where you'd do that.

It's disappointing to hear propTypes is going away - I've found it very useful for dynamically creating type-checking, such as in falcor-shapes-prop-types.

[luisrudge]

please don't remove proptypes.

[ajwhite]

Do you have an example of how you would use Flow to define the types for props? I can't quite connect the dots of where you'd do that.

Curious to this point as well. I assume this might be pretty 1-to-1 with type aliases to describe the props?

[zpao]

Since people have been coming in from Reddit… PropTypes are not being removed anytime soon.

[cpsubrian]

FWIW, one of the best uses of proptypes for me, personally, is that my eslint config (via standard) points out props I use that aren't defined. This helps spot and fix countless typos before they cause a real problem, especially during refactors. I suspect/hope Sublime has equally useful integration with however Flow defines proptypes.

[ljharb]

Until flow runs as a command line tool with no server, and no boilerplate comment in a file I want to run Flow on, it's just not an option. I hope propTypes continue to be developed until such time as Facebook considers Flow type notation useful enough to legitimately propose to TC39 to be part of the JS standard.

[eriklharper]

Because PropTypes ships with React, production apps will log console warnings for invalid propTypes, which is pretty useful. Since Flow is for local development only, will React still log these kinds of warning when PropTypes is removed?

[zpao]

Please read my earlier comment. PropTypes are not being removed anytime soon. PropTypes do not log in production applications either, only in development mode. Flow in its current form would only log in CI or on explicit execution (they are static checks after all). The idea of Flow gaining support for a development transform which would embed runtime typechecks has been discussed but we're not there yet.

[sebmarkbage]

Let me also clarify: There is an idea to unify the type system semantics with Flow so that there are equivalent concepts in either direction.

In case people prefer early adoption of the syntax extension that Flow provides (which is being unified with other similar systems so that it can eventually end up on the standardization track) then they could compile those into development time runtime warnings.

However, there would likely be a runtime only alternative without syntax sugar available too. Although it might be less convenient. Compare something like async/await to Promise. If you don't want to use the syntax extension you don't have to. There won't be a requirement to use language extensions to use React. However, all of these are hypothetical ideas and until this becomes real and adopted: PropTypes will remain and be maintained.

It is unlikely that it will evolve in a direction that is incompatible with Flow-unification that is all. If a new unified system does evolve, there will be a suitable upgrade plan.