This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-06
Channels
- # architecture (2)
- # aws (6)
- # bangalore-clj (3)
- # beginners (7)
- # boot (29)
- # cider (26)
- # cljs-dev (52)
- # cljsrn (1)
- # clojure (249)
- # clojure-dev (9)
- # clojure-italy (2)
- # clojure-norway (3)
- # clojure-russia (178)
- # clojure-uk (30)
- # clojureremote (6)
- # clojurescript (91)
- # core-async (4)
- # cursive (8)
- # datascript (3)
- # datavis (1)
- # datomic (6)
- # emacs (3)
- # figwheel (2)
- # hoplon (14)
- # incanter (6)
- # luminus (8)
- # mount (7)
- # off-topic (22)
- # om (25)
- # onyx (41)
- # pedestal (7)
- # re-frame (9)
- # ring (1)
- # spacemacs (4)
- # sql (1)
- # uncomplicate (1)
- # unrepl (37)
- # untangled (90)
- # yada (77)
@danielgrosse I usually have the view/event/subs/db structure per route, or by component if the component is reusable/relatively self-contained
@curlyfry On the other side, it would promote a single db for an component which IMO goes against the one db solution of re-frame
@danielgrosse I'm not sure if I understand, you would still use the global app-db
The db
namespaces I usually set up a particular part of the app-db, as well as the specs for that part
You could do all of that stuff in the same namespace (the top db
one), but I find it gets pretty huge for bigger apps
So you use a db in the different parts but concat them into the main db at initialization?
@danielgrosse Yup! Try having it all in the main db namespace first, and then refactor out as needed when it gets big 🙂
Has anyone been working on this issue since it was closed? https://github.com/Day8/re-frame/issues/210