Clojurians Log v2

if you’re calling the pathom parser directly then just redefining it should work fine, defresolver expands to def but for more complex apps you might want to go with some state management library (mount, integrant, etc) + with tools.namespace for code reload, because often there’re things which have lifecycle semantics (like a server) and if your pathom parser is accessed via the server, you need to reload the server as well

> https://wilkerlucio.github.io/pathom/#_the_environment_plugin > Typically the parsing environment will need to include things you create and inject every time you parse a query (e.g. a database connection) and some parser-related things (e.g. the reader) that might be the same all the time. What is the purpose of having something like the db connection in the environment argument? My connection is defined in another namespace and managed by mount and I've just been requiring it in the namespace where I define my mutations and accessing it directly as required rather than putting it in env and getting it out of there in my mutation. Is there a reason to do it another way?

If db is defined on env, you can just assoc your test-db and run your test

yeah, it’s the classic DI vs. global state question. I would argue that the DI approach is superior albeit it introduces more indirection

which makes @souenzzo’s case possible without restoring to mount’s own mocking system

@ericihli there’s also a consistency consideration: env plugin injects the env on every parser call so that you have the same db value in all resolvers in that call