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

Reference documentation for properties #652

Open
kovasap opened this issue Feb 27, 2022 · 5 comments
Open

Reference documentation for properties #652

kovasap opened this issue Feb 27, 2022 · 5 comments
Labels
documentation Documentation improvement

Comments

@kovasap
Copy link

kovasap commented Feb 27, 2022

Beyond the examples in the main README, I'm confused about what properties I can supply to a schema and what they do when it comes to validating against that schema. For instance, if I want to encode a map with two keys exactly, one of them known, I would expect something like this to exist: [:map {:size 2} [:timestamp int?]], but I have no way of quickly verifying that it does.

Does this documentation exist anywhere, or is there some code where all these properties are concisely described?

@Invertisment
Copy link
Contributor

You may use the generator to find out what are the generated results

@kovasap
Copy link
Author

kovasap commented Apr 9, 2022

Could you be a bit more specific (maybe supply an example line of code)? I'm not quite sure how to do what you are suggesting.

@Invertisment
Copy link
Contributor

Invertisment commented Apr 9, 2022

I found your issue on clojure reddit:
https://www.reddit.com/r/Clojure/comments/tykor2/malli_schema_questions/

The guy answered most of your questions. I'm not sure what you're trying to do here.

If you're out of luck when README fails to explain then look for tests that test that keyword option map.
I don't think there is such code that you'd have all properties defined in one place. It could exist in tests but you have to find it.

Also it's an alpha-level lib. Don't expect everything to be handed to you. It's possible that features that you'd like simply don't exist at all.

@kovasap
Copy link
Author

kovasap commented Apr 9, 2022

What I'm trying to do is find out the canonical way the Malli authors intend for people to interact with their library. In this case, is the intended way to read through test code? Is it to run some generator function like you first suggested? Is the intention for users to look this stuff up in documentation that doesn't yet exist? IMO the answer to this question is very useful for newcomers to know.

Even with your answer and the response on my reddit post, it's still unclear to me what the user journey would be for this particular case. What path would you take if you were trying to discover all the possible properties for a specific schema element?

I'm not "expecting" anything to be handed to me by you or the library owners - it's an open source project after all. These posts just document my yet unanswered questions. If people are inspired to answer them, then hopefully the posts serve as helpful guideposts for future library users (part of the reason I prefer to post here as opposed to on services like Slack). If you want to just tell me to RTFM you're free to do so :).

@frenchy64
Copy link
Collaborator

I don't think there's a definitive reference yet for which properties are supported by which schemas. It's a little inconsistent so it's probably worth writing.

eg., I think :registry is supported everywhere, but :min/:max is supported by :string, and :vector, but not :map or :map-of (which would have solved your original question).

The way I found that out was to scan the readme for any properties, and then try them out on different schemas in the playground. Reading the source code may also help in the interim, especially working backwards from implementations of malli.core/-validator.

@vharmain vharmain added the documentation Documentation improvement label May 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Documentation improvement
Projects
None yet
Development

No branches or pull requests

4 participants