malli 2020-04-06 | Slack Archive

dcj00:04:08

Regarding map schemas: To get all the map keys from the schema itself: (mapv first (m/map-entries my-schema)) So far there have been two different cases where I need to get all the "encoded" keys from the schema itself, is there any way to do that? For the moment, I have defined the "key-encode-fn` and I store that away in the schema, then when I need the encoded keys, I go fetch it, and (mapv (comp key-encode-fn first) (m/map-entries my-schema) And when I am creating the encoders for a key related mt/transformer, again, I go get this function, and (partial -transform-keys key-encode-fn) This all works if I define and follow the convention above. Is there another/better way to get the "encoded" keys from a schema?

dcj00:04:08

For the record, defining transformers with :compile can be difficult to get correct, until you get an accurate mental model of when in time the various parts really happen on the 'def time' vs 'execution time' continuum. I struggled with this for a while, then eventually went back to a working example @ikitommi gave me, and put printlns at various places. That really helped! Finally I got it working! Very useful and powerful!

dcj01:04:25

A map-entry is a 3tuple vector containing [`key ?properties schema]` , and as data/text, the properties is/are optional... If you've been following along with my "map-schema with support for Postgres tables" example(s), one map entry might like like this:

[:id {:optional true
        :postgres/type :column
        :postgres/datatype :bigserial
        :postgres/key :primary} int?]

Functionally, this is working great. From a schema readability perspective, IMHO, there is quite a lot of "textual distance" between the key, and the schema, when properties are specified/used, I really need to search for the schema of this key... So far, the schemas I have specified for keys are textually simple/short (mostly the built-in ones, or similar predicates I have created) Given that malli is "Pre-alpha, in design and prototyping phase" I wonder if switching the order of the propertes and the schema in a map-entry would improve readability/comprehension... Disclaimers: maybe this is a terrible idea. I have only a small number of hours of experience with malli, and only with pretty simple map schemas. I imagine this change would be extremely painful for everyone involved, and that could easily outweigh any benefits (assuming there are any benefits). I will happily live with the current map entry structure...

Kevin07:04:02

An alternative is adding :id to the registry as {::id int?}. and then using the upcoming map syntax (if this pr gets approved https://github.com/metosin/malli/pull/194)

(def my-registry {::id int?})

(m/schema  
  [::id {:optional true
        :postgres/type :column
        :postgres/datatype :bigserial
        :postgres/key :primary}]
{:registry my-registry})

Something like this. And I think it will be easier to extend the registry later (if I'm reading the issues / PRs correctly)

Kevin07:04:13

Also I think the reason for this format: [key ?properties schema] is because it's inline with the Hiccup syntax https://github.com/weavejester/hiccup Meaning that it would be a bit couter-intuitive to change the order. I could be wrong though.

dcj15:04:31

Seems like it depends on how ‘terminal’ the schema element in a map-entry is. If the schema element was going to describe a another map/list/etc, then switching the props and schema would be horrible, which is probably why the current ordering is the way it is....

dcj16:04:40

Which is the case with the example schema grounded_sage showed in a subsequent post. So now I see why the current ordering is best. Never mind....

dcj16:04:18

NEVERMIND, I now see why current element ordering is best.... A map-entry is a 3tuple vector containing [`key ?properties schema]` , and as data/text, the properties is/are optional... If you've been following along with my "map-schema with support for Postgres tables" example(s), one map entry might like like this:

[:id {:optional true
        :postgres/type :column
        :postgres/datatype :bigserial
        :postgres/key :primary} int?]

Functionally, this is working great. From a schema readability perspective, IMHO, there is quite a lot of "textual distance" between the key, and the schema, when properties are specified/used, I really need to search for the schema of this key... So far, the schemas I have specified for keys are textually simple/short (mostly the built-in ones, or similar predicates I have created) Given that malli is "Pre-alpha, in design and prototyping phase" I wonder if switching the order of the propertes and the schema in a map-entry would improve readability/comprehension... Disclaimers: maybe this is a terrible idea. I have only a small number of hours of experience with malli, and only with pretty simple map schemas. I imagine this change would be extremely painful for everyone involved, and that could easily outweigh any benefits (assuming there are any benefits). I will happily live with the current map entry structure...

grounded_sage15:04:43

I’m having trouble updating a schema. Not sure how to do it. Current schema

[:map
   [:Data
    [:map
     [:CommunicationChannels
      [:vector
       [:map
        [:Identifier [:map [:Value string?] [:Details [:map [:ID string?] [:SystemID string?]]]]]
        [:ChannelType [:map [:Type int?] [:Name string?]]]
        [:Content string?]]]]]]]

Desired schema ->

[:map
   [:Data
    [:map
     [:CommunicationChannels
      [:vector
       [:map
        [:Identifier [:map [:Value string?] [:Details [:map [:ID string?] [:SystemID string?]]]]]
        [:ChannelType [:map [:Type int?]
                       [:or
                        [:Name "EMail"]
                        [:Name "Mobile"]
                        [:Name "Fax"]]]]
        [:Content string?]]]]]]]

grounded_sage16:04:30

Oh figured it out. Have to use the :enum

👍 4

Kevin20:04:02

I'm trying to run the malli tests locally, but getting the following error: Exception: clojure.lang.ExceptionInfo: Kaocha ClojureScript client failed connecting back.

Kevin20:04:35

This doesn't happen in CI though. And I do have some tests that are actually failing, but this error is swallowing them all 😕

Kevin20:04:55

Does anyone else have this issue?

Kevin20:04:12

MacOS Catalina, by the way