Fork me on GitHub
#mount
<
2016-05-06
>
tolitius14:05:03

@zane: can you give a simple example (of how states are connected)? also are you running (mount/start) or (mount/start a b c)?

zane18:05:31

@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.)

zane18:05:51

How do people organize their defstates? Separate namespaces, or co-located with related non-mount code?

tolitius20:05:19

@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

zane20:05:46

Right on. None of those is more idiomatic than any others?

tolitius20:05:51

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

tolitius20:05:17

but again depends on what your preferences / requirements are