This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-01
Channels
- # aatree (1)
- # admin-announcements (11)
- # beginners (77)
- # boot (73)
- # braid-chat (29)
- # cbus (3)
- # clara (3)
- # cljs-dev (16)
- # cljsjs (2)
- # cljsrn (68)
- # clojure (149)
- # clojure-austin (1)
- # clojure-czech (2)
- # clojure-miami (8)
- # clojure-poland (28)
- # clojure-russia (165)
- # clojure-ukraine (1)
- # clojurebridge (3)
- # clojurescript (64)
- # community-development (1)
- # core-async (27)
- # core-matrix (2)
- # cursive (38)
- # data-science (2)
- # datavis (4)
- # datomic (3)
- # dirac (78)
- # emacs (10)
- # events (1)
- # funcool (6)
- # hoplon (25)
- # immutant (2)
- # jobs (3)
- # ldnclj (34)
- # luminus (4)
- # mount (23)
- # off-topic (26)
- # om (121)
- # onyx (320)
- # other-lisps (1)
- # proton (13)
- # re-frame (33)
- # yada (3)
Hello folks, I’m curious if there’s a good to handle indirect dependencies. For instance, I have a state that represents a connection to an SQS queue. In development, I’m using ElasticMQ to act as an SQS interface, and using a state to represent the server. Nothing depends on the namespace, but it must be loaded before SQS.
@wkf: are you looking for a way to specify the order in which these states need to start?
this is something that I don't have an answer for yet but definitely something we discussed before: i.e. "don't start subscribing events to an event bus, until the bus is started".
in case of direct dependencies, this is not a problem, of course, since the compiler shares its intel. But in case of "one off" states, it is not very deterministic.
there are 3 ways I currently use to achieve the desired order (for now, until we come up with a better solution):
1. Have namespaces with one offs to be required last in the entry point on the app
2. Use (mount/start-without a b c)
, and then do (mount/start)
3. If there are only a few states, you can do (mount/start e d a b c)
If I understand your use case correctly there are two questions there:
#1 Not connecting to the real ElasticMQ
in dev
#2 Starting a server before connecting to the queue
You can definitely go with swapping the ElasticMQ
with a stub, but in case you do need it in development, something like (mount/start-without #'app/elastic-mq)
and then (mount/start)
will ensure that everything is started before #'app/elastic-mq