Clojurians Log v2
malli
Is there an option to support blank string in :enum schema. :maybe supports nil but not blank values. currently i used [:or empty? [:enum "foo" "bar"]] to do this validation but is there a way to create a optional-enum registry that supports this scenario. The problem I'm facing using :or is I'm getting two error messages for each options. It would be better to have one message that says, value can be blank or either one of the valid values
[:enum "" "foo" "bar"] should work
https://malli.io/?value=1&schema=%5B%3Aenum%20%22%22%20%22foo%22%20%22bar%22%5D
however error message will hide empty string
["should be either , foo or bar"]
Thanks @delaguardo
Hi guys, I came across https://github.com/metosin/malli/issues/125 when looking for ways to "instrument" functions.
My question is, how do you guys "instrument" functions with malli at the moment?
Hey folks 👋 Are you aware of any generators built on malli ? Interested in crux pull vector, pathom resolvers, entity constructors, fulcro queries
commented on the instrument issue, sorry for the lag.
https://github.com/metosin/malli/issues/349#issuecomment-823596409
@d.ian.b do you mean value generators or schema generators (providers)? Both would be cool. plan is to support EQL for slicing schemas at some point.
I don't mind things being in core if they don't require dependencies but if it's going to bloat the malli dep tree would prefer separate modules so I can keep my projects lean. Maybe that's an easy way to draw the line?
To me seems that at first glance it'd be better to separate all functionality that isn't essential to make Malli works in separated libs, but if we think about Malli as a full experience in terms of how to deal with schemas - and I hope that it became the best in class tool to work with external data, to such a point that people of other ecosystems really envy the Malli experience - I think that the full-batteries included is a better approach, so I really don't mind if all those niceties are included on Malli itself.
oh, and merged 414, breaking change for the extender api. But schemas can now be described with schemas (just need to describe all schemas first :)), the new IntoSchema protocol:
(defprotocol IntoSchema
(-type [this] "returns type of the schema")
(-type-properties [this] "returns schema type properties")
(-properties-schema [this] "maybe returns :map schema describing schema properties")
(-children-schema [this] "maybe returns sequence schema describing schema children")
(-into-schema [this properties children options] "creates a new schema instance"))also, most malli.utilfunctions got bit faster as schema instances now have a direct handle to parent, no need to create new instances. which is nice.
e.g. ´m/type` is looked via the parent:
(defn type
"Returns the Schema type."
([?schema]
(type ?schema nil))
([?schema options]
(-type (-parent (schema ?schema options)))))so, the public api remains the same.
Uhh, I think the wrong I.F. 🙂 /cc @ognivo