Fork me on GitHub
Andrew Byala05:11:36

Is there a recommended way of programmatically adding a component to an Integrant config? I have two components, handler and processor, which both depend on a common component, state. This state is simply an atom of an empty map, nothing fancy. I was able to get this to work with an edn file that in part looks like this:

{:state {}
 :handler   {:state #ig/ref :state}
 :processor {:state #ig/ref :state}}
It doesn't take up much room, but that blank definition for :state isn't bringing any value, and it clutters up the file because I'm not using any configuration values. I tried removing that line from the edn file while keeping in its ig/init-key :state function, but that didn't work. The best option I've found, other than just dealing with it, is making a separate file with only blank configurations (here just {:state {}}), and merging it with the "real" configuration file. Is this a non-problem, or do other folks avoid these top-level empty declarations?


If you do have an atom (that's not what this code shows?) then you could just supply it directly in the config map of each component that needs it, instead of as a ref. That might feel tidier, but if your state init/halt functions are doing real work I see no problems with this code.

Noah Bogart15:11:51

at some point you’re gonna need to write the equivalent of (assoc ig-state :state {}), right? Either it’s in the config file as you have it, or it’s in a line of code you write in a preprocessor. At least when it’s in the config file it’s explicit and lets you see the path of dependencies, unlike something that hides how it actually works (which would happen if you, say, changed the resolution system to create nil fields when referencing an non-existent field).

Andrew Byala19:11:00

Right. I had just hoped that ig/init-key could look for the multimethod without needing to find a match in the edn file, but I suppose it's just not there. And you're right - better to show the dependency at the cost of a tiny bit of extra config. Thanks!

Noah Bogart19:11:49

something i’ve come to do is leave all of those as nil so it’s very obvious that they aren’t passing anything interesting in

👍 1
Andrew Byala19:11:47

I like that idea. It looks very clear.