This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-18
Channels
- # announcements (2)
- # aws (3)
- # beginners (35)
- # boot (10)
- # cider (33)
- # cljs-dev (22)
- # clojure (58)
- # clojure-belgium (1)
- # clojure-europe (8)
- # clojure-houston (1)
- # clojure-italy (47)
- # clojure-nl (2)
- # clojure-spec (4)
- # clojure-uk (39)
- # clojurescript (12)
- # cursive (18)
- # data-science (1)
- # datomic (2)
- # emacs (24)
- # figwheel-main (29)
- # fulcro (24)
- # hoplon (14)
- # juxt (6)
- # kaocha (3)
- # nrepl (6)
- # off-topic (64)
- # om (1)
- # om-next (1)
- # pathom (21)
- # pedestal (18)
- # planck (40)
- # protorepl (1)
- # re-frame (15)
- # reagent (7)
- # reitit (16)
- # shadow-cljs (184)
- # spacemacs (4)
- # test-check (33)
how are people using namespaced keywords in reframe dbs?
Something like
{:long.namespace/value [1 2]
:long.namespace/other-value [3 4]}
Or
{:long.namespace {:value [1 2]
:other-value [3 4]}}
I prefer the second option actually, and it makes it easier to do things like spec validation
but sadly the project I'm working on uses the first approach
u mean in literals @andrea.crotti? ('cos both those approaches produce =
values)
oh, no they don't... i misread
yeah it's not the same
the second option encapsulates a bit better imho, and it's easier to reason about a sub-db
or can I still extract easily a sub-db with the first option?
you would have to filter
rather than just get
to extract a sub-db with the first option
you mean a select-keys
with all the namespaced keys?
or someone filtering with just :long.namespace
?