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

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

I then should be able to say this, right?

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

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}},

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

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

also, fn-schema doesn't pass on properties

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

Is Malli a good place to handle default value ?

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

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

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

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

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.

2 & 3 👍

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

sure

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

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

We likely shouldn't do that

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

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

I'm still using transducers where possible

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

and using fempty etc

cool. Sorry, Need to go.

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

Cool, PR incoming

Catch you later!