Clojurians Log v2

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

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

True, though with-redefs is thread local

yep, hence the let in the start

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.

well, in that case true

but I don't really see how that could happen

mount-lite supports parallel starting and stopping :simple_smile:

ok :simple_smile:

then alter-var-root? :simple_smile:

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

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

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

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

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

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

all my use cases were covered by using a config ns

and pulling values out of it in other defstates

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

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

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

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

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

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.

@schaueho: could you expand on the problem?

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

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)

then you need to mock your API

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

yes, that's what I was thinking

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

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

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

not really

your state should be something that has a lifecycle

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

and then substitute that

or you can just redef the functions directly

the problem here is that you need a different implementation

I would probably prefer protocols, but that way lies component

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

I usually do good old with-redefs :simple_smile:

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

but anyways, thanks for the feedback

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

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