Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-04-20

Channels

#malli
<
2021-04-20
>
Sathiya08:04:56

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

delaguardo08:04:20

however error message will hide empty string

delaguardo08:04:46

["should be either , foo or bar"]

anonimitoraf11:04:42

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?

Ivan Fedorov18:04:34

Hey folks 👋 Are you aware of any generators built on malli ? Interested in crux pull vector, pathom resolvers, entity constructors, fulcro queries

👋 3
ikitommi21:04:15

commented on the instrument issue, sorry for the lag.

anonimitoraf06:04:12

Thanks for the update! Looks good!

ikitommi21:04:52

@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.

clojure-spin 2
refset22:04:12

Uhh, I think the wrong I.F. 🙂 /cc @U0A5V8ZR6

❤️ 3
👍 3
Ivan Fedorov06:04:35

I mean codegen. I want to describe malli schema and then have all the goodies (pull vectors, pathom resolvers, etc) generated. I may end up doing it myself, just asking if you have seen anything like this already.

💯 5
ikitommi08:04:36

don’t think such things exist yet, go for it 🙂 the current malli lib has a lot of optional ns’s for external things (json schema, dot, etc), not sure where the limit should be - what optional things should be in the core lib (as optional namespaces) and which should be separate libs. At least EQL<->Malli could be in the core. Or then just redesign the code into a monorepo like reitit and make all the extras as separate modules.

👍 9
rutledgepaulv02:04:05

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?

👍 4
marciol15:04:59

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.

ikitommi21:04:20

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"))

ikitommi21:04:34

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.

ikitommi21:04:19

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)))))

ikitommi21:04:46

so, the public api remains the same.

ikitommi08:04:36

don’t think such things exist yet, go for it 🙂 the current malli lib has a lot of optional ns’s for external things (json schema, dot, etc), not sure where the limit should be - what optional things should be in the core lib (as optional namespaces) and which should be separate libs. At least EQL<->Malli could be in the core. Or then just redesign the code into a monorepo like reitit and make all the extras as separate modules.

👍 9