This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-22
Channels
- # aatree (2)
- # beginners (14)
- # boot (190)
- # cider (16)
- # cljs-dev (15)
- # cljsjs (6)
- # cljsrn (7)
- # clojure (101)
- # clojure-austin (26)
- # clojure-berlin (2)
- # clojure-estonia (4)
- # clojure-greece (53)
- # clojure-russia (46)
- # clojurescript (44)
- # core-async (12)
- # cursive (57)
- # data-science (49)
- # datomic (5)
- # emacs (8)
- # hoplon (92)
- # ldnclj (20)
- # lein-figwheel (22)
- # leiningen (4)
- # mount (37)
- # om (103)
- # onyx (26)
- # parinfer (70)
- # proton (6)
- # re-frame (32)
- # reagent (1)
- # yada (24)
@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))
The only problem is that you have to choose one or the other, unless there's a way around that
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
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))
is that what you are looking for?Would only, swap-states and swap be defined in mount.core?
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
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
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
I'm just using my workaround for now
@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.