Clojurians Log v2
integrant
hey all! i'm trying out integrant in my app and it's going well enough, but i have a question that's not answered by the docs: i want access to the object created by integrant/`init-key` so i can reference it in the rest of my app. is that possible?
if not, should I bind the result to an atom and then (reset! state nil) in halt-key! ?
oh, this is the returned object from init, not init-keys. nevermind, i have figured it out
actually, follow up. my current app has a function connect which connects to the running mongo instance using an aero config file, and then uses defonce to create a db var with the returned mongo db connection
and then in the meat of the app, that db var is required and used, which assumes that the connection has been made and the var has been defined, etc
I'd avoid using defonce with integrant
or to be broader, I'd avoid global defs for state with integrant
what is the more functional approach to write something like that?
just return the state from an init-key
and it'll be in the system map
and if your other component needs it, #ref that in the config
i'm sorry, i meant in a function like
(defn superusers []
(mc/find-maps db "users" {$or [{:isadmin true}
{:ismoderator true}
{:tournament-organizer true}]}))the current codebase is filled with functions like this, that assume the connection exists in the db var
is it better to pass the integrant system into all of these calls? or to assign it to a global variable and require it?
If you need a quick first pass, I'd go with the former out of those two
but you could make that fn a component itself sort of how handler/greet returns a function at https://github.com/weavejester/integrant#initializing-and-halting
that page doesn't load for me
apologies, wrong link
or you could make a component that returns a reify over a protocol, wrapping your db and exposing all the db-needing functions
hmmmm interesting!
or some groupings of functions in between one-fn-per-component and all-db-fns-in-one
that's suitable to your usecases
yeah makes sense
i'll have to think about this a bunch, see what makes most sense
the point of integrant is that you build up components that are self-contained enough so that other, dependent components only need to pass in args that are relevant to their usecases
You can eliminate most if not all global state this way as all of it will be inside the system map.
yeah, that's definitely the goal cuz it's a ball of spaghetti right now
hah, I've learned that not even integrant can guarantee spaghettilessness 😄
23 different namespaces require that db var, which makes it "easy" but also very messy and means we have to be careful when writing tests or running things individually
you can have one component per namespace for example
each returning something that wraps its functions, requiring the db component
by "wraps its functions", do you mean:
(defn example [{db :system/db}]
(defn db-fn1 [arg]
(do-something db arg))
(defn db-fn2 [arg]
(do-something db arg))
...)Not really, more like:
(defn example [{db :system/db}]
{:db-fn1 (fn [arg] (do-something db arg))
:db-fn2 (fn [arg] (do-something db arg))})even better if you create a protocol defining the interface for fn1 2 etc
and reify that within example
thanks for the example, that's helpful
you're welcome
that's a neat trick. i realize i'm asking a lot, but do you have any projects/examples of that kind of logic?
I'm afraid I don't have anything I'd be allowed to share. But integrant is a phrase specific enough that a github code search should give you some examples
coolio, thanks so much for the help
Nb, good luck! It takes a little getting used to but it's worth it