Clojurians Log v2

@taylor.sando: good point. there is definitely a limitation on composability that I working on at the moment: https://github.com/tolitius/mount/issues/47 I like try not to add new locking API, and focus on composing things. for example here is what I am thinking about:

(-> (only 1 2 3)
    (with-args {})
    (except 2 1)
    (swap {2 42 1 34})
    (mount/start))

btw, as of 0.1.9 mount has both start-with and start-with-states

https://github.com/tolitius/mount#swapping-alternate-implementations

The only problem is that you have to choose one or the other, unless there's a way around that

correct, they do not compose, which is a problem I am going to address with #47 :simple_smile:

what do you think about:

(-> (only 1 2 3 4)
    (with-args {})
    (except 2 1)
    (swap-states {4 #'foo.bar/5})
    (swap {2 42 1 34})
    (mount/start))

as a temp workaround you can have test states (that would create values you need), and use them along with real states via start-with-states

another "reverse" way is to use that datomic connection as a value

and close it / clean it at the end of the test

(i.e. could be in fixture)

any way you go, I'd like to know what worked / did not work for you :simple_smile:

Well for a 0.2.0 release, a way to explicitly state which states you want to use, and then the ability to provide state and value replacements

that's what I am thinking by:

(-> (only 1 2 3 4)
       (swap-states {4 #'foo.bar/5})
       (swap {2 42 1 34})
       (mount/start))

Would only, swap-states and swap be defined in mount.core?

yep

Would it be building up a map then?

You could potentially keep start-with, and create a new start-using so that you don't have to overload start/with

more like a set

yea, the old API would not change, and the start takes states since day one

the idea is to have as few API as possible :simple_smile:

and once they are composable, there is only going to be a need in start and stop that optionally take vararg states (the way they already do)

I guess the swap-states and swaps would just be side effecting like start-with-states and start-with is now

right, for yurt it would not matter since all of it is going to be detached once the yurt is built

for mount no changes from the way it works now

i.e. which one to use would mostly depend on personal preferences and the development flow

it is interesting that you want both swap-states and swap.. I was contemplating on removing start-with-states, since in tests values work better, and most of the real states have their start / stop functions live separate, hence can be reused to create / destroy those values

is there any reason just values (i.e. the current start-with behavior) won't work for you?

Seems like it would be easier to manage the start/stop then using values and fixtures

yea, that was my thinking

oh.. read it wrong

my thinking was reverse :simple_smile:

in any case I'll keep both

in the meantime would a couple of workarounds above work for you?

I'm just using my workaround for now

ok, sounds good. I'll let you know once the composable approach is in

@taylor.sando: You might like https://github.com/aroemers/mount-lite. You won't have the issue with dev states starting with it (substitutions are "anonymous" to mount-lite), all the start options are composable via data (and have composable convenience functions), and substitutions have lifecycle expressions.

@taylor.sando: not to ditch mount at all though, I know @tolitius is working on your issues as well.