Fork me on GitHub
Slack Archive

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

2023-01-13

Channels

#malli
<
2023-01-13
>
escherize00:01:34

Is anyone setting up mock functions with malli? It’s so cool! 

(mx/defn eff :- string? [x :- int?]
  (str x))

(def mock-eff (mg/generate (m/form (:schema (meta #'eff)))))

;; mock called with good input, returns output that matches the return schema
(mock-eff 3)
"72eSV3WQpD6d9"

;; mock throws (just like the real thing would) on bad input
(try (mock-eff "3")
     (catch Exception e (ex-data e)))
;; => {:type :malli.core/invalid-input,
;;     :message :malli.core/invalid-input,
;;     :data {:input [:cat int?], :args ["3"], :schema [:=> [:cat int?] string?]}}

🚀 4
👍 4
2
jeroenvandijk07:01:41

Nice trick! Thanks for sharing. Maybe also interesting to start with this implementation and complete it when you need to.

✅ 2
ikitommi09:01:48

@escherize Malli instrumentation has a :gen option for the lazy:

wow 6
🚀 2
pithyless15:01:08

How would you approach customizing the generators for these kind of mocks? Would it be custom :gen at the mx/defn level? Or override the schema with custom registry at the (partial mg/generate)? Or something else?

ikitommi15:01:30

not at the computer, but I think you can add :malli/gen meta to the var

escherize16:01:46

I generally have dev running when.. in.. dev. Is there a filter for that gen key?

escherize16:01:52

It’d be nice to put a metadata on a function definition and have it autogen, then take it off recompile and no autogen. Maybe this already exists

☝️ 2
jeroenvandijk14:01:50

So in theory you could build an application this way without filling in the details and have it somewhat working. And if it doesn’t work it would be logical errors like reusing a password, maybe other uniqueness like things, but you could get pretty far I guess. Sounds good!

escherize15:01:00

I think it’d be good for mocking an api for your hypothetical front end team

Noah Bogart19:01:59

Would there be any interest in having humanize say the type that's given? Instead of just {:some-num ["should be an integer"]}, it could say {:some-num ["should be an integer, given a string"]}

👍 2
escherize23:01:15

but I agree it’s better to say the type that was given

ikitommi08:01:44

yes, adding the humanized value type into the error message makes sense - as an optional :wrap impl for example.

👍 2
☝️ 2
Dallas Surewood19:01:53

When writing encoders/decoders for a transformer, is there a way to match by schema and not just :int or function symbols? For instance 

(defn x-transformer [] (mt/transformer
                     {:decoders {'str-stat-schema (fn [x] (:value x))}
                     :encoders {'str-stat-schema (fn [x] {:value x})}}))
Was hoping that would work. Would like to make decoders to convert one schema to another

ikitommi08:01:41

what is a 'str-stat-schema here?

ikitommi08:01:46

you can attach decode functions into any schema at the moment, e.g. have any schema control how it’s being decoded. If you want to push the control to transformer, there has to be a way to identify the schema. it can be any data pulled out of a schema.

ikitommi09:01:03

here’s one way to do it using schema references (references need to be strings of qualified keywords): 

(let [schema [:schema {:registry {::str-stat-schema :string}}
              ::str-stat-schema]
      decoders {::str-stat-schema (fn [x] (:value x))}
      encoders {::str-stat-schema (fn [x] {:value x})}
      compiler (fn [schema _] (when (m/-ref-schema? schema) (m/-ref schema)))
      transformer (mt/transformer
                   {:default-decoder {:compile (comp decoders compiler)}
                    :default-encoder {:compile (comp encoders compiler)}})
      decode (m/decoder schema transformer)
      encode (m/encoder schema transformer)]
  ((juxt identity decode (comp encode decode))
   {:value "kikka"}))
; => [{:value "kikka"} "kikka" {:value "kikka"}]

ikitommi09:01:25

but, it’s much easier to inject the encoders & decoders into schemas: 

(def str-stat-schema
  [:string {:decode/custom (fn [x] (:value x))
            :encode/custom (fn [x] {:value x})}])

(-> [:map
     [:x str-stat-schema]
     [:y str-stat-schema]]
    (m/decode
     {:x {:value "kikka"}
      :y {:value "kukka"}}
     (mt/transformer {:name :custom})))
; => {:x "kikka", :y "kukka"}

ikitommi09:01:32

hope this helps

Dallas Surewood17:01:02

This was helpful. The plan was to make easy transformations to convert from one schema to another. The first option may be best for that, but it's very verbose. I suppose I should just make my own functions that do this manually.

dvingo19:01:37

I've been working on integrating malli with react-hook-form for a bit (mostly learning react-hook-form :P ), and now have something working! https://github.com/dvingo/malli-react-hook-form You can play with it here: https://dvingo.github.io/malli-react-hook-form/ I'm sure there may be some tricky things for more complex data shapes, but this is a promising start!

👍 2
3
escherize23:01:26

Looks familiar! I wrote a POC for something similar a long time ago. http://escherize.com/works/data-desk

escherize23:01:39

it’s still really cool though

dvingo01:01:17

no worries! that's definitely the direction I'm heading :D (generating forms from schemas) this part was just figuring out wiring of the pieces of reusable parts, next will be outputting these from the schema

ikitommi09:01:17

good to see work on malli->forms! I really would like have that, have few non-complete prototypes and most likely no time to finish.

wcalderipe11:01:44

I'll share a fresh thread from #clojurescript here in an attempt to connect people with similar issues https://clojurians.slack.com/archives/C03S1L9DN/p1673488701932789

escherize23:01:22

I uploaded the lastest version of my version lately too: https://escherize.com/works/data-desk/ I think to do it right requires using a similar strategy to malli/experimental/describe.cljc where there’s a multimethod over the schema types. Might be cool to do using htmx, too.

dvingo01:01:42

nice! do you have the source published or no? And yep for sure, will need to deal with all the built in schemas plus nested/refs