Fork me on GitHub
#malli
<
2023-06-23
>
didibus10:06:49

Also curious if there's been any thought around something similar to Spec2 schema/select for Malli? Any experiment on that front?

Craig Brozefsky13:06:35

I regularly use malli schema transform operators to do this -- including defining input and storage derivatives of schemas that identify my domain entities. I have also used the utils for making keys required or optional, to build derivative schermas for input and "compiled" forms for expressions in DSLs. Malli schema are data....

Craig Brozefsky13:06:39

see malli.util(mu). mu/required-keys, mu/optional-keys, mu/merge, mu/select-keys, mu/closed-schema, mu/open-schema ....

Craig Brozefsky13:06:10

So I can define a "canonical" schema for an entity, then use those to derive input (aka, POSTing) schema. Those would disallow some keys, like the computed id. Same with storage, which might have more "computed" fields like timestamps.

nice 2
hifumi12318:06:36

yup, I use malli.util fairly often too. mu/keys is especially useful in frontend applications when I'm submitting form data and want to submit only the actual keys ive validated for the form

didibus18:06:53

Cool, I'll take a look at these. I've been using multi-spec in Spec1. But it's not as ergonomic, since you have to manually copy/paste all versions of your schema, and then you don't have a place where you can see the full union.

didibus18:06:26

I guess there's not something exactly like select, that would make everything optional except for the selected keys which would be required. But I can probably do something myself that does this.

hifumi12318:06:15

you should be able to use a mix of union, selected-keys, and required-keys to recreate the behavior

hifumi12318:06:11

(mu/union (mu/optional-keys schema)
          (mu/required-keys (mu/select-keys schema ks)))

hifumi12318:06:14

i would guess this

didibus18:06:31

Oh, nice, ya if optional-keys has an arity that just optionals everything, that should work.

eval202014:09:02

I recently released https://github.com/eval/malli-select to allow for spec2-like selection of malli-schemas. Feedback welcome!

🎉 3
ikitommi15:09:44

Nice! I’ll add this to README and mention it in the malli 0.13.0 announcement 🥳

🙏 1
fabrao17:06:20

Hello all, is there possible to include some Vendor extension into the parameter of swagger schema result, the x-examples? Like here:

... "paths" : {"/v1/show-informations" : { "post" : { "parameters": [{ ..., "x-examples": { ...
?

ikitommi09:06:40

does adding :swagger/x-examples work? e.g. [:int {:swagger/x-examples [1,2,3]}]

fabrao15:06:03

No, it should be as another parameter like:

"parameters": [
{
"in": "body",
"name": "Request Timelines Payload",
"description": "",
"required": true,
"schema": {...},
"x-examples" : {...
},
but if I use "swagger/x-examples": *{*"x-examples": *{ ...* into :parameters it's including outsite of in: body , like
"parameters": [
{
"in": "body",
"name": "Request Timelines Payload",
"description": "",
"required": true,
"schema": {}
},
[
"swagger/x-examples",
{
"application/json": {
"simple-example": {
"summary": "Simple Example",
"values": {
"someRequest": "REQUEST INFORMATION"
}
}
}
}
]
I want to know how to include it into in body, if possible

mafcocinco20:06:00

I noticed in there is a start! and stop! function. It seems these functions, or at least start! would be useful for instrumenting all functions that were in scope outside of a development context. The name of namespace gave me pause WRT using start! in production code. Would likely not need to call stop! outside of a dev context but I prefer a single function to instrument all functions in a single stop rather then having to sprinkle mi/collect! calls throughout all namespaces that use function schemas. So, 2 questions: 1. is there any gotchas/harm in using outside of a development context (re: production code)? 2. Is calling mi/collect! within each namespace the accepted way of instrumenting functions using defn metadata or is there a better/similar way to !?

ikitommi09:06:06

hi. You could use in prod, or just call the relevant malli.instrument functions in case you don’t need things like automatic Var watching, clj-kondo settings, pretty errors etc. e.g. the stack is: 1. malli.core/-instrument - pure functions 2. malli.instument/collect!|instrument! - side-effecting one-time functions 3. ! - side-effecting, adds developer things like pretty-printing

mafcocinco13:06:15

Yeah. I ended up going with collect and instrument. The part that I found most useful within was the {:ns (all-ns)} options to collect!. Didn’t realize you could do that and was worried I was going to have to include a call to collect! in every namespace that used function schemas.

mafcocinco13:06:31

Thanks for you help @U055NJ5CC.