This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-06
Channels
- # admin-announcements (6)
- # beginners (147)
- # boot (9)
- # braveandtrue (5)
- # cider (11)
- # cljsjs (1)
- # cljsrn (4)
- # clojure (82)
- # clojure-greece (9)
- # clojure-poland (9)
- # clojure-russia (288)
- # clojure-taiwan (2)
- # clojure-uk (73)
- # clojurescript (123)
- # consulting (3)
- # cursive (26)
- # datascript (4)
- # datomic (32)
- # dirac (56)
- # emacs (11)
- # flambo (2)
- # hoplon (425)
- # jobs-rus (1)
- # lein-figwheel (3)
- # leiningen (16)
- # luminus (42)
- # mount (7)
- # om (1)
- # om-next (2)
- # onyx (8)
- # other-languages (146)
- # quil (3)
- # re-frame (17)
- # reagent (6)
- # spacemacs (2)
- # uncomplicate (8)
- # untangled (71)
- # vim (2)
- # yada (49)
@zane: can you give a simple example (of how states are connected)? also are you running (mount/start)
or (mount/start a b c)
?
@tolitius: I figured it out. State b
was dependent on state a
, but a
was being replaced with b
via mount/start-with-states
. (Overriding a production config with a development one.)
How do people organize their defstate
s? Separate namespaces, or co-located with related non-mount code?
@zane: I've seen several approaches: 1. Have a defstate and functions that use (i.e. reference) it in a single namespace 2. Have defstates defined with accordance to the module / package / layer / namespace of an application 3. Have defstates defined in a single place and referenced from other namespaces
I would say it depends.. i.e. for data access I would have a defstate
of the db connection and query functions in the same ns, or if there are many of those, would separate them out into read/write/delete ns.. for config and other ubiquitous states, I would keep them all in one place and reference them from other namespaces