Currently there is not really a Calva option for this. A similar question was asked here: https://clojurians.slack.com/archives/CBE668G4R/p1716921933970019

I would go for a manual two step thing. First run Calva refresh, then when it is done have a shortcut configured for resetting component. As suggested here: https://github.com/BetterThanTomorrow/calva/issues/2556

thanks for the answer, @pez! One question, is it possible for me to kinda "hijack" or override (don't know the right word) this cider command in some file like my project's user.clj file, and pass these options? maybe there is some crazy clojure function I don't know

No such crazy function around that I know of.

FYI: https://github.com/BetterThanTomorrow/calva/pull/2565

Relevant documentation update: https://deploy-preview-2565--calva-docs.netlify.app/commands/

As a heavy user of Component myself, I would recommend developing a workflow that does not rely on refresh at all, if possible. Eval every change you make into the app running in your REPL, and use tips like https://clojure.org/guides/repl/enhancing_your_repl_workflow#writing-repl-friendly-programs to ensure you can update functions without needing to restart/refresh your components. I work with a codebase of 145k+ lines of Clojure, with about two dozen services in it, and I have several of those running at once in my REPL and work for days sometimes without any sort of refresh/reload process.

hey @U0ETXRFEW!! just saw the Calva update, you are the man, thanks for that!! I'm using it right now

@U04V70XH6 totally agree, but the problem is when I need to use programs that are not that repl-friendly 😕 I mainly did this because I use pedestal with reitit routing (for openapi 3.0 generation) and it does not have any way of reloading changes made to route handlers automatically (just like vanilla pedestal or reitit :rolling_on_the_floor_laughing: ) so this is the solution I'm able to give now

Which option did you go with, @U05RN5LFB54? Providing after to the refresh command or runCommands?

I find both useful, but I ended up going with runCommands because it fit better with my custom setup, I replace the cmd+s behavior when the Calva REPL is connected so it can save my files and load them in the REPL:

{
        "key": "cmd+s",
        "command": "runCommands",
        "args": {
            "commands": [
                "workbench.action.files.saveFiles",
                "calva.refresh",
                {
                    "command": "calva.runCustomREPLCommand",
                    "args": "(when-let [reset-fn (resolve 'com.stuartsierra.component.repl/reset)] (reset-fn))"
                },
                "workbench.action.terminal.scrollToBottom"
            ],
        },
        "when": "calva:connected"
    },

I read that reitit now supports vars for handlers so you should be able to get more REPL-friendliness from it now...?

@U04V70XH6 I wish 😕 I have the same problem of this thread: https://clojurians.slack.com/archives/C03S1KBA2/p1687996968925419 still no solution, will probably try to switch from pedestal to ring some time in the future

btw, have you taken a look at the clj-reload integration? https://github.com/clojure-emacs/cider-nrepl/blob/6ec50c3fe97c618243d2c6eaa4cd2f2ee35a4205/CHANGELOG.md#new-features

I saw them mentioned browsing the code. It looked almost like they are being used also with refresh, but I probably read that wrong. What’s the difference?

They're different nrepl ops (`refresh` vs. cider.clj-reload/reload) backed by different libraries As clj-reload keeps gaining traction it seems worthwhile to give users the choice 🙂

It’s unclear to me what the users are choosing between, though. What’s the significance of using one over the other?

This is summarized in https://github.com/tonsky/clj-reload?tab=readme-ov-file#comparison-toolsnamespace - it appears to be more featureful and flexible. Old bugs aren't present anymore. Personally I appreciate both libs, I keep using t.n for reasons, but clj-reload seems to have a brighter future and probably will keep moving much faster than t.n (as it often happens with other clojure org projects)

Thanks. Very enlightening! What are your reasons for using tools.namespace at times?

I have a personal fork with parallelism 😇 (I wouldn't publish that - it works for me but don't want the responsibility)

Awesome. Seems like “doesn’t work with ClojureScript” is a reason to keep the t.n option around.