This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-23
Channels
- # admin-announcements (1)
- # announcements (1)
- # beginners (222)
- # boot (210)
- # cider (26)
- # cljs-dev (50)
- # cljsrn (19)
- # clojure (243)
- # clojure-art (12)
- # clojure-finland (1)
- # clojure-poland (43)
- # clojure-russia (46)
- # clojure-sg (13)
- # clojurescript (60)
- # core-async (14)
- # css (11)
- # datomic (9)
- # devcards (9)
- # dirac (2)
- # editors (13)
- # emacs (5)
- # euroclojure (1)
- # events (3)
- # hoplon (76)
- # immutant (10)
- # job (1)
- # jobs (2)
- # keechma (1)
- # ldnclj (33)
- # lein-figwheel (1)
- # leiningen (20)
- # luminus (26)
- # mount (31)
- # om (105)
- # onyx (56)
- # parinfer (29)
- # perun (12)
- # proton (1)
- # re-frame (14)
- # reagent (5)
- # sydney (1)
- # yada (15)
i’m having a problem where i have defstate defined in a file to start up my db connection, but it only starts if i explicitly load-file in my REPL
just to clarify: you have two namespaces A
and B
you have your defstate
defined in A
in the namespace B
you call (mount/start)
and the database connection state does not start
is that accurate?
when you load the program, at the entry point i.e. (mount/start)
, namespaces need to be required in order for mount
to see them. that does not mean you have to require all the namespaces with defstate
s since most of them would be brought in transitively (similar to how dependencies are resolved with lein / boot / maven), but something needs to tell your entry point namespace what it is "you'd like to work with"
@taylor.sando, see if this resolves the issues you had: https://github.com/tolitius/mount/blob/0.1.10-SNAPSHOT/README.md#composing-states
@tolitius: I believe swap
and swap-states
are side effecting? Have you thought about naming them swap!
and swap-states!
?
@tolitius: The composing does work Does yurt also need to change, because I don't see a way of using blueprint
@taylor.sando thx for checking. I'll update yurt a bit later. just wanted to first make sure mount works
@arnout: I thought about it, but then I am not a "purist", and in this case thread side effects do not affect the application, and mostly affect mount internal state, which is later rolled back to its original state on (mount/stop)
.
+ most of the time these functions will be used together in composition right before the call to (mount/start)
.. e.g. which by itself is side effecting.. just not in the "business" context of an application
+ in yurt these will be detached after created, and will live locally
.... :)
@tolitius: true, and they are also fine to use inside clojure.core/swap!
, alter
etc, as substitute!
is idempotent. Still, users might be suprised if they have something like:
(def config-a
(-> (only #'a #'b)
(swap {#'a :some-substitute})))
(def config-b
(-> (only #'b #'c)
(swap-state {#'b #'d})))
(mount/start)
Maybe it is not your intention to have users use mount/your composable functions like that, but hey... users
yea, for these presets I would not recommend def
ing them. but rather use data, which I might add later. the whole concept is not immensely useful ( my opinion ), but very good to have, so I don't want to make it more complex than it needs to be. yes, there is room for error, but if you are already in a position where you splitting state configs, you'd probably know what you are doing
the only place where the data approach is really useful, might be lein profiles, since lein is declarative