Thanks. Dunno what’s the added benefits of sci.

The benefit of SCI would be if you would like to serialize your schemas to the front-end

The quote is only needed for serialization

Then why not a custom export function to convert function to its symbol names. I am not quite getting the actual benefits compared of importing sci here.

Because just a symbol won't give you evaluation in the client

When client are you referring to the js environment? Also, pardon me, are we assuming sci could run on js (given the recent work of nbb and such)

yes, JavaScript

you can include malli on the client side and then use SCI to evaluate your schemas and get exactly the same validation as on the server

So you can send your schema's dynamically to the client

> So you can send your schema’s dynamically to the client That is so futuristic, that I am not sure I am ready.

In the latest version of the README the examples have been changed to not require SCI unless mentioned.

I think this particular one is now

(m/decode
  [string? {:decode/string clojure.string/upper-case}]
  "kerran" mt/string-transformer)
; => "KERRAN"

Malli started with simple keywords everywhere, but as the options are passed everywhere, this doesn’t scale well -> moved to use qualified keywords. Could clean up all options for 1.0.0?

One ideas was to have default global options map, could be read from EDN-file, set like the registry etc and which could be tune all different parts of the system. Not there yet.

I’d like to learn more on the scale well part. When I am writing something only used internally, I will use qualified keywords, because this helps jump to usage, bulk rename, etc. But when I am providing some opts map for the user, I will use simple keyword. Mandating qualified keywords kinda complicates the opts map.

Malli options has :`registry` being the only reserved simple key. There are some qualified keys used in core like ::m/walk-entry-vals, which are relevant only in a special use case (here, using m/walk). If we had two option arguments ("how the system is configured" and "how this use case should work") we could use simple keys in both. Now, it's just one arg, and I think it's better to namespace the latter keys to avoid conflicts and to document which ns owns them. You can merge 'em all into one map and pass it everywhere.

I recall there are two open issues related to how to manage the global options better. Both would introduce a breaking change in the public APIs.

I would like to remove the "pass in optional options arg to every function", have ideas on that, but, need to think about it first.

Here is a good example on bad and good option naming: https://github.com/metosin/malli/blob/master/src/malli/error.cljc#L332-L361