Feature request: warn when property not in propTypes is passed into component

[jameslong]

It would be great if in debug mode react would warn you when you pass in a property on props which is not specified in the propTypes object for that component. i.e. a way to enforce that props should ONLY have the props specified in propTypes and no others.

This would prevent use of undocumented properties and also allow better code maintenance as unused props would be more easily removed.

[syranide]

To add to this, why does isRequired only emit a console warning? I assume it has to do with not wanting to use invariant for dev-only (same behavior dev and prod), but it's a little weird.

[zpao]

We want this too :) @sebmarkbage has some plans here. One idea recently was this: https://github.com/reactjs/react-future/blob/master/01%20-%20Core/08%20-%20Transferring%20Props.js

It's a bit tricky because of transferPropsTo (or whatever we do instead) where you might have props that need to be passed on even if you don't consume them.

Eg <FancyButton className="foo" color="blue" /> which renders this.transferPropsTo(<button value={this.props.text} style={something with this.props.color} />). You want the className to make it through even though you didn't explicitly say that FancyButton uses that.

[zpao]

@syranide that's a tangential discussion but ultimately we skip propType checks in prod (they are slow to perform on every update). So we can't use invariant and have different runtime behavior in dev vs prod.

[sophiebits]

I'm not 100% convinced that we can't use invariant() for prop types in dev only, especially given that the implementation here of warning() is not very aggressive.

[syranide]

@zpao @spicyj Tangential discussion I agree, but just to state my opinion on this. I agree that different behavior in dev and prod is bad... but to me it's about warnings being very easily missed, when something isRequired and isn't provided, it is an error, please tell me! I don't see it any differently than asserts, which are usually not shipped in prod, but stops execution if they fail in dev. An error that exists only in dev isn't really an issue, it's helpful. An error that exists only in prod is a huge red flag.

[slorber]

@jameslong another idea could also be to have a "strict" config in the JSX compiler that will refuse to compile JSX files if they use components without passing all the declared propTypes.

It would only work for JSX components however, but will not affect React at runtime in DEV or PROD...

That way it's like guaranteeing that a component is used in a typesafe way by its clients.

I don't know if something like this would be easy to do, I suppose it could be complicated with transferPropsTo and things like that...

[syranide]

@slorber Since the set of props aren't necessarily very static at all it can't be resolved at compile-time, especially not if you consider that it must also verify the type of each prop.

[slorber]

Yes at compilation time, it can at most be a best effort to try to find obvious component misusages but will not really be typesafe...

The props are not static but if the parent has a string props and it's passed to the child, at least this can be verified that the same type is passed from the parent to the child, and could issue a warning is the parent proptype is "any" while the child has "string" because this "casting" may be unsafe

[syranide]

@slorber If you can't guarantee something at compile-time then you still have to pay the full cost at run-time (for DEV). I agree though that there may be some potential in doing the most basic checks of static types at compile-time, but I'm also doubtful that it would really be worth it... if you didn't even bother testing it once in DEV (which would throw an error in your face) before going PROD then you have bigger issues to deal with on your end.

[WickyNilliams]

I'd just like to chime in to say I'd love this feature.

I always start out with best intentions, documenting all the props. But as I develop further, propTypes inevitably get forgotten about. In my mind propTypes are a contract/interface and any non-documented props should be treated as a violation.

Even if an error is preferable, a warning (as with mismatch) would be better than the what we currently have.

[mczepiel]

Was about to create a duplicate of this issue myself; it would be appreciated to help keep track of the state of things when I'm in the midst of adding a new feature or refactoring.

[slorber]

yes it would be nice and somehow goes in the direction of Facebook Flow?