Fork me on GitHub

Runtime defined specs/schemas have also a good use case with web apis & dynamic forms. I’m thinking of creating a MapSpec -kinda Spec Record which would allow non-registered (global) specs to be used and which could manipulated as normal Clojure Map. Adding generated specs to registry at runtime might not be a good idea...


Related: toyed with a simple collection spec macro that allows specs to be created from nested maps/vectors/sets. Should help to define partially anonymous map specs. For things like http query-parameters.


emits just recursively s/keys & s/coll-ofs.


Hmm... but I think after runtime modification of a MapSpec, one would still need to have the full source-code of it for the s/form to work. So adding values at runtime would require both the value and it’s source code to be added. Removing keys would be easy, same as merging existing MapSpecs. Maybe not such a good idea after all.


ikitommi: Interesting - I was having similar thoughts about the possibility of building more specialised libraries that can consume ::specs - for more dynamic use cases… e.g. you could imagine something like plumatic being able to consume specs in some circumstances- It seems you’re a long way ahead of me 🙂


still very much at the getting started stage with spec


rickmoynihan: we are all still spec newbies, exiting times.


@ikitommi Talk to me about that runtime specs you are planning. I've just written down my requirements for this kind of thing yesterday and would love to collaborate.