What is the project's stance on officially supporting "map" data in the API?

[torbensky]

I've been struggling to find a reasonable way to use this library to validate a "map" type of structure. Specifically I want to validate an object with unnkown keys that must have a certain type of value for any keys defined. Basically the same thing as an ES6 Map. In Typescript it would be something like this:

interface Foo {
  [key: string]: T
}

I believe this is an extremely common and fundamental data modeling design pattern. So I was pretty surprised to find that there wasn't an official API for handling this type of data.

In my attempts to solve this need, I found the following issues which seem to all be related:

• How to implement yup.map()? #690
• how to write schema for Map<key, value> alike structure? #657
• How to create a "Dictionary" in a schema? #524 (comment)

In that last issue that I listed, the project maintainer has also identified that this is a common request. Based on my own research into this problem, having read a lot of other peoples' comments in various issues, I agree that it is common. I ran into this limitation within the first day of trying out yup.

I've spent a lot of time reading through the other issues hoping to find a solution. So far I have been unable to find a workaround that works. Many solutions seem to be incompatible with recent API changes or with Typescript environments. They seem to all require an understanding of the yup internal API's so that users can add a custom extension to the library. Many users seem to have resorted to unsatisfactory workarounds or given up.

I feel that the UX of any proposed workarounds for this problem are poor, even if they do work, but often they don't seem to. That's in contrast to the overall UX of yup which I think is very good. It's generally taken me just a few minutes to find a robust way to handle most validation use cases. It would be great to also solve the map use case in a way that provides that same great experience that this library otherwise has.

Unfortunately I'm getting the impression that this project has no interest in solving this use case in a more robust way. But I don't want to jump to conclusions so I thought I'd just ask. I understand that it may be a challenging problem to solve and that the maintainers are busy people.

Does this project have any interest in solving the "map" validation use case? Preferably by offering a documented, concise way of using fluent API's to validate such a type.

• edited: formatting/typo

[torbensky]

TLDR;

I'm askng if the project would accept this feature because the responses to the other issues seem to indicate a reluctance to solve the map use case directly in the library.

[jquense]

The reluctance is due to the nature of the feature. A general map schema is not something I've found myself needing very often (compared to the other built in types). Most times i did want to reach for something a one off lazy schema or a transform to an array, worked just as well. Similarly with many of the folks who have requested it. That's not to say that my use-cases are the correct ones, lots of ppl use yup, and have different constraints and needs. The reason i mention it though, is that ultimately I have to maintain anything in the library and more complex data structures like a map are a lot more complex to maintain than you might think.

My conclusion in the past has been the overall complexity, library size increase and ongoing maintenance costs of supporting a map directly is disproportionately high compared the benefit, especially since there are fine, albeit uglier, workarounds. That said i'm generally always open to ppl proving me wrong with regards to complexity and code size