mount

tolitius 2016-05-06T14:19:03.000212Z

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

zane 2016-05-06T18:30:31.000213Z

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

zane 2016-05-06T18:30:51.000214Z

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

tolitius 2016-05-06T20:34:19.000215Z

@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

zane 2016-05-06T20:34:46.000216Z

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

tolitius 2016-05-06T20:52:51.000217Z

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

tolitius 2016-05-06T20:53:17.000218Z

but again depends on what your preferences / requirements are