Fork me on GitHub
#mount
<
2016-02-14
>
arnout11:02:36

@tolitius (or anyone interested), I am curious to know your opinion on https://github.com/aroemers/mount-lite/pull/5 simple_smile

dm311:02:09

hm, that seems like syntactic sugar on top of

(def ^dynamic *i* 10)

(defstate incrementer
  :start (let [i *i*] (fn [n] (+ n i)))
  :stop ...)

(with-redefs [*i* 20]
  (mount/start))
am I missing anything? Doesn't seem all that useful

arnout11:02:17

True, though with-redefs is thread local

dm311:02:41

yep, hence the let in the start

arnout11:02:41

No, that would not work, if the with-redefs in your example is done in another thread than where the the :start expression is executed.

dm311:02:05

well, in that case true

dm311:02:19

but I don't really see how that could happen

arnout11:02:32

mount-lite supports parallel starting and stopping simple_smile

dm311:02:52

then alter-var-root? simple_smile

dm311:02:26

anyway, I don't see the value of bindings (in my limited world of using mount)

dm311:02:45

could you maybe describe what you're using them for?

arnout11:02:46

Hmm, yes. Would be more stateful though, requiring an extra (global!) var and remembering to reset it after a (stop).

arnout11:02:07

I'm not, currently simple_smile It was just an idea I had this morning.

arnout11:02:41

I thought it would be a nice solution for having some DI and argument passing.

arnout11:02:49

Good to know though, that you would not find it useful, thanks simple_smile

dm311:02:00

all my use cases were covered by using a config ns

dm311:02:11

and pulling values out of it in other defstates

dm311:02:52

IMHO neither component, nor mount should be present in libraries (except for an optional integration)

arnout11:02:42

I see. And yes, I share that humble opinion.

schaueho14:02:13

Hi there, I have a (maybe simple minded) question on mount usage with regard to substitutions

schaueho14:02:04

I'm starting from the point of view that I might want to change behavior when I substitute some state, in particular for testing purposes

schaueho14:02:34

I don't see any obvious ways how mount would support that, am I right?

dm314:02:17

you substitute your state with something that you control, right? Something that would change the behaviour based on what you need in the test? E.g. mock database connection instead of a real one.

dm314:02:29

@schaueho: could you expand on the problem?

schaueho14:02:56

yes, e.g. my real db connection would be to a mongo db, but the mock db would then need quite different implementations

schaueho14:02:44

so, the real db has a "find-docs" function and the mock one, too, but obviously with quite different behavior (e.g. using atoms for the data storage)

dm314:02:38

then you need to mock your API

dm314:02:25

the functions in the NS, as seemingly you're not testing the mongo implementation but the things that use it

schaueho14:02:55

yes, that's what I was thinking

schaueho15:02:23

just to explain a bit, the send-sms example on the mount homepage was throwing me off a little

schaueho15:02:04

the substituted state looks like a normal object to be used by some function, whereas the substitute is a function

schaueho15:02:45

so I was wondering if the idea would be to have callables as states

dm315:02:50

not really

dm315:02:07

your state should be something that has a lifecycle

dm315:02:40

you can create a MongoUserDb and MockUserDb types that implement a UserDb protocol

dm315:02:54

and then substitute that

dm315:02:04

or you can just redef the functions directly

dm315:02:53

the problem here is that you need a different implementation

schaueho15:02:05

I would probably prefer protocols, but that way lies component

schaueho15:02:29

there are also some other smaller libraries to help with this particular problem

dm315:02:15

I usually do good old with-redefs simple_smile

schaueho15:02:02

with-redefs is fine for testing, but doesn't help with decoupling dependencies

schaueho15:02:13

but anyways, thanks for the feedback

arnout15:02:25

@schaueho: Using a UserDb protocol as @dm3 suggests would be the way to go. The issue you describe is not solved by either component or mount. Protocols solve your issue, and are still a good thing simple_smile Mount still lets you use protocols, but you don't have to (as with Component you easily fall in the trap of putting everything in a protocol).

tolitius23:02:27

@arnout: what would be an example of using the bindings idea in case a state is a resource?