Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validate a map's key type and value type #4

Open
qimingweng opened this issue May 17, 2015 · 3 comments
Open

Validate a map's key type and value type #4

qimingweng opened this issue May 17, 2015 · 3 comments

Comments

@qimingweng
Copy link

Would be cool to have!

For example

map: ImmutablePropTypes.mapKeyValue(PropTypes.string, PropTypes.number)
@HurricaneJames
Copy link
Owner

I have never used anything but strings or numbers as keys, especially for data I'm passing as a prop. I am curious what your use case is for needing to map the type of the key?

I should have some time next week to work on this. Right now I'm working on a writeup for another project. If you already have an implementation, I'm open to a PR.

@qimingweng
Copy link
Author

I still use primarily strings as keys, but there are three-ish scenarios (all somewhat vague, I'll admit) that I've found a need for something like this

  1. I use PropTypes also as a form of documentation on what the data the component uses should look like. So it's useful to be more declarative about what the keys are, for example, PropTypeAccountID = PropTypes.string.
  2. If IDs (or keys) have to adhere to a certain string format (ie, 6 or more characters), I can use PropTypeAccountID = PropTypes.customProp(...).
  3. I've made the mistake before of generating optimistic object ids as numbers before the server generates strings, and it's possible to expect Map keys as strings but get numbers instead, so even just to distinguish between strings and numbers can be useful.

But I do love this little library 😄. I haven't had time to implement yet but if I do before you I'll submit a PR.

@Aldredcz
Copy link
Contributor

Actually implemented in PR: #30

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants