This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-24
Channels
- # arachne (1)
- # bangalore-clj (11)
- # beginners (177)
- # boot (63)
- # business (1)
- # cljsjs (21)
- # cljsrn (3)
- # clojars (4)
- # clojure (116)
- # clojure-art (4)
- # clojure-belgium (3)
- # clojure-india (1)
- # clojure-italy (6)
- # clojure-russia (14)
- # clojure-spec (8)
- # clojure-uk (67)
- # clojurescript (51)
- # community-development (5)
- # cursive (13)
- # datascript (14)
- # datomic (29)
- # devcards (3)
- # emacs (3)
- # events (3)
- # funcool (4)
- # hoplon (29)
- # mount (6)
- # om (34)
- # om-next (5)
- # onyx (16)
- # perun (8)
- # planck (22)
- # re-frame (13)
- # reagent (5)
- # ring-swagger (21)
- # rum (3)
- # spacemacs (3)
- # specter (1)
- # untangled (39)
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.
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