Proposals for new React.PropTypes

[chicoxyzzy]

PropTypes.exactly

I took use case below from some gitter chat where @JustBlackBird wanted some property to be String or exactly false. So maybe he can add some comments here.

Use case

PropTypes.oneOfType([
  PropTypes.string,
  PropTypes.exactly(false)
]);

instead of

PropTypes.oneOfType([
  PropTypes.string,
  PropTypes.oneOf([false])
]);

PropTypes.range

It is very common case when we need prop to be a Number in some range. Let's say it should be percent value from 0 to 100 or other inputs with type range for example.

Use cases:

PropTypes.range(0, 100);

or even

PropTypes.number.integer.range(0, 100); // only integer numbers. subproposal!

Another example

PropTypes.range(-Infinity, -0); // negative numbers only

[chicoxyzzy]

actually I don't sure PropTypes.range is a good idea because prop may become invalid only in production and this will lead to potential errors when developers rely on PropTypes and don't validate props inside their components but I'll leave this proposal here for further discussion

[quantizor]

@chicoxyzzy PropType checking is disabled in production

[chicoxyzzy]

@yaycmyk sure. That's why devs may not have warnings in production and if they do not validate data in their components this will lead to potential production-only errors which is bad thing

[quantizor]

Yeah, I also just took a second look over all the current PropTypes and none of them are so granular beyond the typing and shape of the given prop. All other more specific matching criteria are meant to be implemented as a custom prop type.

[rmilesson]

Why do you have a prop that is either a string or false? How are you using that? Sounds a bit like bad design.

[JustBlackBird]

false can stands for e.g. "no value"

[gaearon]

Currently, as far as I know there are no plans to add new features to PropTypes.
The longer term plan is to use Flow instead (and potentially add optional runtime validation to Flow).

See #3510 (comment).

[rmilesson]

@JustBlackBird That's what null is used for.

[JustBlackBird]

@rmilesson, then you can treat it as "string or null" condition =)

It actually does not matter. The point is to explicitly pass "no value" to component.

[rmilesson]

@JustBlackBird My point is that you should not use strings and booleans interchangeably. I mean, you can, absolutely, but it's pretty bad form.
Use null if you want to signify when something might get a value, but hasn't yet. It's clearer.

[JustBlackBird]

Ok, you've got you. Even if I want to use null or string I should use validator like:

PropTypes.oneOfType([
  PropTypes.string,
  PropTypes.oneOf([null])
]);

(So it does not matter null or false is used.)

And this proposal is about adding PropTypes.exactly validator.

[rmilesson]

No. Not at all.

PropTypes.string would suffice in that case. Unless you add isRequired (I suggest reading #2166).

Edit: A better approach would be to allow null values if a prop is required. At least in this case.

[JustBlackBird]

That is the point. isRequired + (string or null) allows to check if "no value" is passed explicitly and is not forgotten by accident.

[jimfb]

@JustBlackBird If it was forgotten by accident, it would be === undefined. If it was passed explicitly but simply has no value, it would be === null. In the interest of API intuitiveness, It's probably not a good idea to use a non-standard sentinel value.

Proptypes are mostly legacy and in maintenance mode, having been replaced by tools like Flow. My guess is we aren't going to add this, so let's close it out. We can re-open if our thinking on this matter changes substantially.

It is worth noting that proptypes are just validator functions. You can define your own, and share/distribute your own proptypes. This is the optimal outcome, because people can download the additional proptypes if they find them useful.