You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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?
The text was updated successfully, but these errors were encountered: