@seancorfield I use component.repl/reset to make sure all namespaces are reloaded

I eval every change as I make it so my application running in my REPL always reflects my code. I went through Eric Normand's REPL-driven development course and he says he doesn't use a reload/reset -- and Stu Halloway has said the same about his REPL process.

Both ProtoREPL and Chlorine for Atom have options to enable that sort of thing (automated reloading) but it seems to just get beginners into trouble (when it fails -- which it often seems to do) so I tend to recommend turning all that off.

I'm always a bit curious about someone's workflow when I hear they rely on it.

I don't see it mentioned that often but I like to use https://github.com/riverford/objection for this. Basically I just want a way to rescue myself from the situation where I have state that needs to be shut down and I accidently lose a reference to it, which I somehow always end up doing. Objection basically just keeps a bunch of stop-fns in an atom for you that you can call when needed. I think there's a fundamental difference between start and stop . I'm fine with handling starts from regular code but I do kind of want a way to stop everything.

(I actually probably don't even need objection now that I think about it, for the way I use it. I could probably just use an actual atom of object -> stop-fn)

@jjttjj Interesting. I hadn't heard of that one before so thank you.

For working in the REPL, I tend to keep a defonce Var in a "Rich Comment Form" in my source code (defonce app (component/start (app/system ,,))) and then have a (component/stop app) form as well. Or I can alter-var it (again, via code inside an RCF). But since I can have multiple live "systems" running at the same time in a single REPL I don't find much need to stop them very often -- and since I always eval code changes into the REPL as I make them in source files, all those running systems get code updates at the same time so, again, they mostly stay in sync with the source code.