Fork me on GitHub
#malli
<
2019-12-12
>
beders01:12:57

it looks like m/fn-schema doesn't allow for any other parameters (or children)

beders01:12:39

here's what I tried:

(defn max-length?
  ([n s]
   (and (string? s) (< (count s) n)))
  )
(def default-registry (merge m/default-registry {:max-length (m/fn-schema :max-length preds/max-length?)}))

beders01:12:18

I then should be able to say this, right?

(m/validate [:max-length 4] "bubu" {:registry default-registry})

beders01:12:02

but alas

#error{:cause ":malli.core/child-error",
       :data {:type :malli.core/child-error, :data {:name :max-length, :properties nil, :children (4), :min 0, :max 0}},

beders01:12:42

which - when checking the code - happens in fn-schema

beders01:12:15

it seems -partial-fn-schema allows for additional parameters, but is private

beders01:12:57

also, fn-schema doesn't pass on properties

beders01:12:52

any hints on how to register custom predicates with params would be awesome

Johan05:12:52

Is Malli a good place to handle default value ?

ikitommi07:12:59

@johan178 sure. could be just :default property and a pre-defined transformer to use that for missing values. metosin/schema-tools has just about that.

ikitommi07:12:46

need to add capability to transform all schemas, so need a small development before it can work. Please raise an issue.

rschmukler19:12:06

Hey @ikitommi I'm in the process of fixing up transforms for independent leaves and enters (and reverse order). I have a few questions for you while I'm in here...

rschmukler19:12:51

1. For the collection transformer, right now fwrap auto-coerces things into the appropriate type. This happens after the value-transformer is called currently - meaning that I don't think it's possible for the value-transformer to change it's collection type on encode because it'll always be coerced back. Should we keep this behavior? 2. the map-of transformer currently calls transform keys and transform values at the same time as it iterates through the map. I think it's fine to keep this for enter and leave? ie. it'll basically be enter: transform-map -> transform k 1 -> transform v 1 -> transform k 2 -> transform v 2 and leave: transform k 1 -> transform v 1 -> transform k 2 -> transform v 2 -> transform map 3. The collection transformer currently does a single step of building the collection and mapping the values. We probably want to do enter: coll-transform -> transform children and leave: transform-children -> transform

ikitommi21:12:23

1) I think the fwrap should be removed and moved under Transformer decoders. e.g. as the arrays are always mapped to Clojure vectors in JSON decoding (by json parsers in both clj & cljs), with mt/json-transformer there should be no transformation needed for :vector, only for other sequence types. The currently silly mt/collection-transformercould have decoders for all collection types.

rschmukler21:12:35

Re. 1 I want to land this PR w/o that then if you don't mind. It's already huge

rschmukler21:12:13

The other thing that we don't do much, that I'm going to add, if you think it's a good idea, is ensuring that the type doesn't change between transforms

rschmukler21:12:33

ie. if a map encodes itself to an integer, we still try and call reduce-kv on it for the key and value transformers

rschmukler21:12:40

We likely shouldn't do that

rschmukler21:12:39

Actually - I'm going to keep this focused at just the changes to fix #140 and the encode decode order - we can add more later

ikitommi21:12:35

btw, the 3 might have a big effect on the perf?

rschmukler21:12:30

I'm still using transducers where possible

ikitommi21:12:35

depending on how the collection is transformed, retaining the type automatically or not

rschmukler21:12:46

and using fempty etc

ikitommi21:12:56

cool. Sorry, Need to go.

rschmukler21:12:59

I tried to be mindful of the performance implications - but a close look is definitely a good idea!

rschmukler21:12:02

Cool, PR incoming

rschmukler21:12:04

Catch you later!