mount

jaen 2016-01-18T12:22:30.000349Z

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.

jaen 2016-01-18T12:23:01.000350Z

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

jaen 2016-01-18T12:23:49.000351Z

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.

jaen 2016-01-18T12:24:28.000352Z

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

dm3 2016-01-18T12:25:18.000353Z

yep

jaen 2016-01-18T12:25:52.000354Z

I see; I'll try that then.

dm3 2016-01-18T12:26:37.000355Z

you can still have "components" in the mount app :simple_smile:

jaen 2016-01-18T12:27:50.000356Z

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.

jaen 2016-01-18T12:28:31.000357Z

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

jaen 2016-01-18T12:29:19.000359Z

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

jaen 2016-01-18T12:30:29.000360Z

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

dm3 2016-01-18T12:33:57.000361Z

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

dm3 2016-01-18T12:34:02.000362Z

so if you have one thing in your app

dm3 2016-01-18T12:34:10.000363Z

it's stored in a var

dm3 2016-01-18T12:35:23.000364Z

and the functions use it as they please

dm3 2016-01-18T12:36:10.000365Z

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

dm3 2016-01-18T12:36:35.000366Z

just Clojure, no special rules

jaen 2016-01-18T12:54:54.000367Z

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

dm3 2016-01-18T13:02:52.000368Z

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

dm3 2016-01-18T13:03:09.000369Z

or store a map/atom/seq in a var

dm3 2016-01-18T13:03:22.000370Z

as you do with component

tolitius 2016-01-18T15:46:39.000371Z

@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])
(names could differ of course..i.e. it can be "connect..", "close", "disconnect", etc..)

tolitius 2016-01-18T15:46:46.000372Z

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 :simple_smile: 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