Clojurians Log v2

FWIW the pattern I’ve settled on is to keep my defstates in a separate namespace than my logic fns, and the state (connections or whatever) get passed in as vanilla fn arguments to those logic fns. It can get a bit unwieldy when you have a logic fn that depends on a lot of different state, but the benefits of having “stateless” logic namespaces seems to me to make up for it. Testing & experimenting at the REPL are greatly facilitated by this approach.

Not saying it’s the best or only way to do it, and keen to hear of better alternatives folks have come up with!

> and the state (connections or whatever) get passed in as vanilla fn arguments to those logic fns when switching from spring this is the hardest part to unlearn, since, as a spring developer you always have this feeling that something is @Autowired into something else (because it is in spring), and when switching to functional languages (about 12 years ago) it took me awhile to not have functions wrap that state. whether you keep your states separately or with is more of a personal preferences (both work well). things to watch out are circular dependencies and keeping those states as thin and low level as possible. I tend to keep a state with its logical module: i.e. "system-a" namespace will have a connection to "system a" plus some functions to work with "system a". but again, the main thing is to design functions in a way that they do not wrap state: i.e. take all the state they need as args. > It can get a bit unwieldy when you have a logic fn that depends on a lot of different state these (potentially) could be good candidates to refactor into several functions and compose them at the edges of the application

100% agree. And yeah I try to write “pure” namespaces focused on providing fns that do one thing and one thing well, and then compose those together somewhere else, alongside all the state (often a “core” namespace).