This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-08-14
Channels
- # aleph (1)
- # announcements (1)
- # beginners (59)
- # boot (2)
- # calva (5)
- # cider (8)
- # clj-kondo (6)
- # cljdoc (5)
- # cljsrn (11)
- # clojure (123)
- # clojure-dusseldorf (1)
- # clojure-europe (4)
- # clojure-italy (22)
- # clojure-losangeles (4)
- # clojure-nl (10)
- # clojure-spec (18)
- # clojure-uk (22)
- # clojurescript (103)
- # cursive (32)
- # data-science (1)
- # datomic (21)
- # events (2)
- # figwheel (1)
- # fulcro (12)
- # graalvm (3)
- # graphql (8)
- # jobs (2)
- # kaocha (4)
- # klipse (2)
- # lein-figwheel (4)
- # leiningen (23)
- # off-topic (11)
- # planck (11)
- # re-frame (8)
- # reagent (2)
- # reitit (3)
- # rewrite-clj (1)
- # ring (1)
- # ring-swagger (31)
- # schema (2)
- # shadow-cljs (66)
- # spacemacs (3)
- # specter (16)
- # sql (9)
- # tools-deps (16)
- # vim (26)
Good Morning! Thanks everyone for the interesting discussion yesterday on keyword arguments and destructuring. Lots of food for thought!
@dominicm that happens where I live now and again. It's terrible, I agree. Can't sleep when that happens (I'm a light sleeper anyway)
Where's the silent black helicopters then? Surely they have them (on loan from Mr Trump?)
morning
Clearly quite late to yesterday’s discussion, but does anyone use the namespaced version of :keys
?
(defn some-fn [{:user/keys [username] :actions/keys [history] :as _opts}]
...)
Or is it more:
{{foo-id :id :as foo} :foo
{bar-id :id :as bar} :bar}
regarding destructuring I’m with @mccraigmccraig… though I’m also not averse to using :keys
. Essentially I’m ok with nesting destructuring forms and the full expresivity of destructuring.
Also I’m fine with it in the fn
args…
I’m not saying that you should deeply nest data — I prefer shallow structures where possible — but if it’s what you’re given, nesting destructuring one level down is fine. Nesting more than that I might question it…
I’d also advocate where you have a nested structure lifting values higher if you can… e.g. on a ring http request you might lift the params/headers up to be top level on a context map, and then have the rest of your code work with that; and not need to know the path to the data.
One place I worked had the :keys [:user/foo]
syntax in the style guide for greppability.
For one namespace I like :user/keys
but if there's more than one namespace involved I think multiple :foo/keys
is kinda messy so I like the :keys [user/username actions/history]
syntax as I feel that symbols are more "correct" in this context than keywords.