This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-06-23
Channels
- # announcements (3)
- # aws (1)
- # beginners (44)
- # biff (6)
- # calva (31)
- # cider (26)
- # clerk (12)
- # clj-kondo (9)
- # clojure (17)
- # clojure-dev (18)
- # clojure-europe (13)
- # clojure-norway (45)
- # clojure-uk (4)
- # clojurescript (34)
- # datomic (54)
- # dev-tooling (14)
- # emacs (19)
- # events (7)
- # honeysql (2)
- # hyperfiddle (51)
- # lsp (34)
- # malli (24)
- # matrix (1)
- # missionary (5)
- # off-topic (27)
- # re-frame (6)
- # reagent (18)
- # releases (2)
- # sci (6)
- # shadow-cljs (88)
- # vim (9)
Also curious if there's been any thought around something similar to Spec2 schema/select for Malli? Any experiment on that front?
It comes up once in a while: https://clojurians.slack.com/archives/CLDK6MFMK/p1678389151150529
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....
see malli.util(mu). mu/required-keys, mu/optional-keys, mu/merge, mu/select-keys, mu/closed-schema, mu/open-schema ....
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.

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
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.
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.
you should be able to use a mix of union, selected-keys, and required-keys to recreate the behavior
Oh, nice, ya if optional-keys has an arity that just optionals everything, that should work.
I recently released https://github.com/eval/malli-select to allow for spec2-like selection of malli-schemas. Feedback welcome!
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": { ...
?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 possibleI 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
?
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
see https://github.com/metosin/malli/blob/master/docs/function-schemas.md#defn-instrumentation
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.
Thanks for you help @U055NJ5CC.
I recently released https://github.com/eval/malli-select to allow for spec2-like selection of malli-schemas. Feedback welcome!