https://github.com/metosin/malli/pull/184 <-- adding the :in to visitor, :path not needed.

fxed :path with :multi schema: https://github.com/metosin/malli/pull/185

as with sequencial schemas, we don’t know the actual index of the value, so added just a placeholder “value here” using :malli.core/in marker. Comments welcome on that.

another options would be to: 1. use -1, e.g. temp-id like in datomic 2. use 0, the first index

re: Form generation based on malli discussed yesterday, I’ve been thinking that since malli has the capability, it could be interesting to provide the entire form with the validator functions from backend - in projects I’ve been eg. translations for error messages are managed on the backend services anyway, so generating a full-blown “form scheme” with not just what the desired data structure is but also how it’s validated and what the translations and help texts, labels etc. are in various languages and whatever else could actually be the most interesting usability wise. This approach would of course mean doing some extra heavy lifting as binding this data would mean the UI component (think React) would need to have indirection to the path to data (both read and updates) instead of being instanced directly with the data, but that is a better architecture anyway. This was discussed in some conference last year, I’ll try to find a link…

For the life of me I can’t find the post/talk. Anyway it was mostly just a suggestion that 1. have global state (eg. re-frame’s db) 2. all components should know only the path to their data in the state (`[:foo :went :to :bar]`) 3. all updates to data is done to that same path What my caffeinated flow of mind above tried to convey was that with this pattern having the malli data to be mounted to some path in semi-generic fashion would allow instancing the form components quite nicely as well 🙂

did you check my code snipplet from above? allows to add the path to data…

ui-components need to know how to handle sequences and :map-ofs, e.g. need to generate / retain indexes for the elementes. for nested maps & tuples, the path can be fully calculated forehand.

Yes, now that I re-read that I think we’re at least in the same ballpark with how it should be.

got me thinking, does malli handle seq keys for maps? 😅 there’s this one terrible API I saw recently which returned data like this {[:foo :bar] :baz [:more] :stuff}

what other ways there are to handle seq keys than to use seqs like in the example?

The first step is to make sure that is even parsed correctly 🙂 afaik python/ruby/php can’t even read that in

(why am I on the weird side of this industry all the time…)

Anyway, the biggest concern with that is that correct validator is matched per key which actually a sequence; in my laziness I made that example uniform while in practice it probably wouldn’t be.