instanceof is unreliable, and doesn't work cross-realm - the only safe way to identify Sets is function isSet(maybeSet) { try { Object.getOwnPropertyDescriptor(Set.prototype, 'size').get.call(maybeSet); return true; } catch { return false; } }.

You can already do what you want by composing PropTypes.instanceOf(Set) with something that checks the values; it's not a bad suggestion though!

(Also, if Set was added, I'd expect Map to be added as well)

Thanks for the feedback @ljharb.

.mapOf would likely require passing two checkers: one for the keys and one for the values.

Any thoughts on the ugly errors?

I don’t see why it must; objectOf doesn’t take a checker for the keys, only the values.

@ljharb That is true.

In which realm does instanceof Set not work?

@Pimm it’s not that; it’s that using a Set from an iframe will return false with instanceof. It’s the reason Array.isArray exists.

I'm interested in this. I've written a PR, though I obviously encountered the issue with the array access operator. I was able to work around it. I'm also quite sure that maps should take two validators, one for keys and one for values. It doesn't make sense to have validators for a dictionary-style object as validated by objectOf since the keys are always just going to be strings. That is very much not the case with Maps.

I hadn't considered the problems with instanceof Set. Here's what I think can be done about that:

• If the instanceOf Set check succeeds, you're fine (obviously)
• If the instanceOf Set check fails, look more closely at the object. Does it have the methods you expect, namely add, has, and forEach. This check doesn't have to be perfect.
  • If you get this far but don't find Symbol.iterator, you're probably looking at an IE10 Set. Fail the check and warn about IE10.
  • If you do find Symbol.iterator keys values and entries, it's pretty certain that what you have is a Set of some description. Warn the user that it looks like they may be encountering a Set from a different realm and, this is the key bit, link to a tinyUrl page about how to fix the problem. On that page recommend that they change their setOf validator to an iterableOf and, if they need the other set methods, internally wrap with a Set which belongs to their own realm.

As a note, I have a temporarily shelved project which would use symbols to allow custom structures like Immutable.Set to declare themselves to follow the Set API, and thus would be suitable for allowing sets to truly be reliably detected across realms.

instanceof Set can succeed on a non-set, and can fail on a real set.

I think the check does have to be perfect.

also note that arrays, Maps, and Sets all have Symbol.iterator, values, and entries.

(Presumably objectOf doesn't take a checker for the keys because the keys of an object are guaranteed to be strings. Map keys can be anything. Edit: Strictly speaking, Symbols can also be keys, but anything else just gets turned into a string. For that matter, Symbol keys don't show up in Object.keys/.values/.entries.)

For me, I see there being two separate use cases at play:

1. I store and pass around Sets at a higher level to easily guarantee against duplicate values, but the component doesn't care that it actually gets a Set. Sometimes it might be odd if it were accidentally passed a prop with duplicate values, but the component is just doing its rendering thing, and any important business rule around duplicates is handled at the source of truth. In these cases, what I'd actually prefer is an iterableOf check for the generic interface that the component actually relies on.

2. The component uses the Set interface, usually has. A setOf type seems like it would be nice, here, except that the component doesn't actually need to get a Set to use has, it just need an iterable it can wrap in a Set.

In both cases, I always want to maintain the ease of passing in a Set, without the component necessarily having to care that it's getting a Set.

The caveat to iterableOf, which in principle would be simple to add, is specifying the shape of the values. Single values are simple enough. Map, though, is an iterable of key-value arrays, e..g ['foo', 15], as is Object.entries. There isn't a product type to match on a heterogenous array like this.

I see three options:

1. Add a top-level product-typed array checker, that matches the types of elements at a specific index of a single array. Downside: People would use this, and product-typed arrays are generally an anti-pattern. Also strictness/non-strict considerations. Also why not support iterables here too, at that point?

2. Support calling .iterableOf with either: a single iterated type; or an array of types that would be checked against the entries as if they were a product-typed array. Downside: potential weird ambiguities around .iterableOf(.string)/.iterableOf([ .string ]).

3. Explicitly limit support to list-like or map-like semantics, with either one or two types: .iterableOf(.string) or .iterableOf(.string, .number). Downside: couldn't match against iterables of product-typed arrays generically.

(Not a big deal IMO but it's worth noting that the nice array/set symmetry you get from treating them as iterables doesn't apply to object/map, since POJOs aren't, strictly speaking, iterables. But that's fine, we already have a type for POJOs.)

Oh yeah you need a top level tupleOf matcher. Then you'd have iterableOf(tupleOf([keyType, valueType])) I think.

I don't think it's worth it to add these validators to prop-types, especially given react's general position on PropTypes as a concept. Here's what I'd suggest in the meantime:

import isSet from 'is-set';
import isMap from 'is-map';
import { predicate, and } from 'airbnb-prop-types';

const set = predicate(isSet, 'must be a Set');
const map = predicate(isMap, 'must be a Set');

cont setOf = (validator) => and([set, validator]);
const mapOf = (validator) => and([map, validator]);

You'll find .isRequired and that all expected propType debugging info is available.

General discussion about the value of PropTypes as a concept don't belong on this issue, or really on this repo at all.