Anyone around here? Thinking of giving mount an another try and I'm wondering how would you approach having a queue component that other components can use in mount.

In component I'd just use whatever record component injected, so each component would have it's own instance of the queue.

But since mount operates on namespace granularity the simplest solution would be to have the queue code duplicated among the namespaces, which is pretty stupid. There ought to be a better way, but it doesn't immediately jump out at me.

A non-mount namespace that has a make-queue that returns something the mount namespace can keep in a def or something?

yep

I see; I'll try that then.

you can still have "components" in the mount app

Yeah, but what I mean is as far as I understand mount components are singleton, since they are just namespaces - you can't have two instances of the same component like in uh... component.

So my understanding is that things you want to re-use across mount namespaces (components) should not be a mount namespace (component).

But this solution seems sensible, I'll see how it works out in practice.

So, thanks for confirming this might be a good idea.

what I like about mount is that you are back to the vars and functions

so if you have one thing in your app

it's stored in a var

and the functions use it as they please

if you have many similar things - have a ns that deals with them with the state being passed as an argument

just Clojure, no special rules

Hmm, but it means you trade the ability to limit the scope of dependencies to a certain component, like you can with component - that is you refer to global singleton components and can't have a dependent component that's locally scoped to a given component (that's a lot of "component" in one sentence). But having a def with a value a non-mount namespace sounds sensible : )

yeah, if you want multiple pieces of state you have to pass them around

or store a map/atom/seq in a var

as you do with component

@jaen: there is no the answer to it, as it would really depend on what the problem permits, I feel like this will definitely get better, as we get questions like yours and discuss among us possible ways to tackle it. just to give you something more to try, think about: I would tend to keep start and stop logic in functions that take configuration:

(defn create-queue [conf])

(defn disconnect-queue [conf])

then we can have options: * have one state that would create map of queues and can be referenced from other states or namespaces / functions * have many different queue states in a single namespace * have several namespaces hosting queue states (if they are "business" different) + some other resource logic that may relate to these queues * have other states that need these queues (locally), just use the above two functions on their :start / :stop * use those two functions in local bindings (i.e. no state needed) * other ways I have not thought about the cool thing about mount (agree with @dm3) is that mount brings you back to just Clojure where it is mostly up to you and the problem at hand to drive the best solution