The prop-types code makes an assumption at the core API level that it will always be possible to traverse the entire props object using only the array access operator, as (value[keyName]).
This assumption breaks when attempting to validate iterables, particularly Sets and Maps.
I have a working implementation of mapOf and setOf validators which I will put up in a PR as soon as I have corporate approval. The problem is that you're validating, say that a Set contains only items of PropTypes.number, there's no way to refer to an item in the set using the array access operator.
Modifying what prop-types does internally is not a major issue, but changing to a pattern that simply gives the value to validate would be a breaking change for the public API of custom validators.
Is there a willingness to follow through on such a breaking change?
For the moment I'm doing a hack: I'm passing the validators [value], 0 for a Set item. It's probably Good Enough for now, but it the error messages don't read quite right.
The prop-types code makes an assumption at the core API level that it will always be possible to traverse the entire props object using only the array access operator, as (
value[keyName]
).This assumption breaks when attempting to validate iterables, particularly Sets and Maps.
I have a working implementation of
mapOf
andsetOf
validators which I will put up in a PR as soon as I have corporate approval. The problem is that you're validating, say that aSet
contains only items ofPropTypes.number
, there's no way to refer to an item in the set using the array access operator.Modifying what prop-types does internally is not a major issue, but changing to a pattern that simply gives the value to validate would be a breaking change for the public API of custom validators.
Is there a willingness to follow through on such a breaking change?