This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # alda (1)
- # announcements (18)
- # babashka (101)
- # beginners (110)
- # calva (17)
- # cider (53)
- # clara (18)
- # clj-kondo (26)
- # cljdoc (6)
- # clojure (152)
- # clojure-europe (9)
- # clojure-portugal (4)
- # clojure-spec (20)
- # clojure-survey (7)
- # clojure-sweden (10)
- # clojure-uk (10)
- # clojured (1)
- # clojurescript (29)
- # core-async (7)
- # cursive (4)
- # datomic (11)
- # defnpodcast (2)
- # dirac (1)
- # emacs (13)
- # events (2)
- # figwheel-main (1)
- # fulcro (1)
- # jobs (14)
- # jobs-discuss (17)
- # leiningen (2)
- # malli (1)
- # off-topic (74)
- # overtone (1)
- # pedestal (4)
- # planck (2)
- # re-frame (7)
- # reitit (4)
- # remote-jobs (4)
- # shadow-cljs (78)
- # slack-help (3)
- # spacemacs (56)
- # test-check (3)
- # tools-deps (6)
Has anyone written a version of spec2 select that works with spec1? Deciding to have keys required or optional for all use cases is so painful 😣
@kenny Not sure what you mean by "works with spec1"? The two libraries use different registries so you cannot combine them (at least, not easily)
When using nested maps, spec1 doesn't let you change which keys in the nested map are required.
That's exactly why Spec2 is coming -- that required/optional thing in Spec1 is painful 🙂
In Spec1 that is complected and baked into how
s/keys works. In Spec2 the set of keys and the requiredness are decomplected.
You know, it just occurred to me — this is going to make it hard to create an interop schema using spec — in other words, to fully describe a data structure that a system expects/requires, including the keys that are required in each map… I suppose we might need to write some new plumbing to create a schema based on some spec2 specs, with additional annotation, expectations, etc. :thinking_face:
I'm not sure I follow. Spec 2 still let's you specify which keys are required, including nested keys. It just teases the two concepts apart.
Hmm for some reason I was thinking that the new
schema function was designed solely for the case of defining function specs… but I haven’t looked super closely 😬
schema? or maybe I’m thinking about
select — I should just review the docs :face_with_rolling_eyes: sorry
schema defines the possible set of keys.
select defines the required subset of a schema.
I just did a walkthrough of a pretty involved schema using spec1 with some members of my team who aren’t familiar with it, and they asked a bunch of questions that I answered with “not right now, but that’s coming in spec2”
Yup, I'm looking forward to Spec2 becoming non-alpha and the "standard" way to work with Spec.
For a while, I had a branch at work tracking Spec2 but with the number of bugs and changes as it has evolved, it was proving a bit much trying to keep our codebase current on it... so I gave up a while back and we'll take another look once it is stable. I doubt we'll migrate, but we'll probably start using Spec2 for new code (and may convert old code over as we maintain it over time).
Ya. Was hoping for a workaround for now. It seems potentially possible to get it to work.
I don't know if
s/merge will let you override an all-optional
s/keys with a subset of keys that are now marked required. Doesn't help you much with nesting I suspect.
You could just start using Spec2 I suppose 🙂 But not for any production work as it's still changing a lot.