integrant

2020-10-15T02:05:32.012700Z

Thanks for your answers Rick. I thought for quite a while about your issue and looked up some things. I did not find existing solutions in this space, as you put it. I was initally going to answer with a wall of text of intimidating proportions, but decided against it out of ... shyness. I'd be delighted to send you my thoughts on the subject if you're interested - feel free to message me privately and I'll dig the (600 words, 3500 chars) thing out.

2020-10-15T02:25:21.013Z

OTOH, and to go back to what Kirill suggested, if some configurations are too complicated for the specs to be enough, maybe the effort should be to simplify them so that specs would be enough.

2020-10-15T07:55:07.013200Z

@zor I’d certainly be happy to read it

2020-10-15T08:04:35.013400Z

@zor: regarding simplifying configurations so the specs would be enough… that can get you a small way there but it’s really not enough. Firstly the configurations can’t really be simplified further. There’s an inherent complexity that is just complex. Also there’s a simple vs easy trade off; simplifying a component usually means splitting it up into more components… making a component easier to configure usually means handling more coercions etc and complecting separate components into one. Secondly the specs can tell you what valid values look like; but they can’t tell you why you want to use a component, or describe what it actually does. Also they can’t provide you with a documented library of components to browse and pick from. Finally you still can’t document specs themselves.

kirill.salykin 2020-10-15T09:57:33.013600Z

thought from another point - would it make sense to have all integrant specific methonds in one place (like main.clj) - and libs/components just provide constructors/create fns (integrant-less)? like

some component

(defn create-db-pool [] ...)
main.clj

(defmethod integrant/init-key […]
  (create-db-pool))

2020-10-15T10:22:14.014200Z

:thinking_face: well that’s certainly not a bad idea