Clojurians Log v2

Very cool. Why use TypeScript, though? ClojureScript is a way better choice. Here’s an extension template I’ve made https://github.com/PEZ/vscode-extension-template if you wanna experiment with that. (Things are a bit outdated, but if you end up going this way we can help eachother getting it up-to-date.

I actually googled for a clojurescript way to get it done but didn't find an obvious result. I'll have a look ! it's not much code to begin with so it will be easy to port over

Really bad SEO for that template! 😃 Only 2 stars, and I think I may be the only user so far. I do hope you’ll go this path! The following extensions use ClojureScript: • #joyride • Backseat Driver (based off of the template) • Calva PowerTools (based off of the template) • Paste Replaced • Calva (very partially) Those by me. There are others, of which I know Clover.

For modernizing the template some, you can ask Copilot to look at Joyride and Backset Driver and list the changes. There are only a few. The most important one is that I have changed so that integration and e2e tests can be run while using VS Code Insiders.

Hi @pez. Dumb question — I’m very new to VS Code Extensions but am kicking the tires on it. How does this extension template relate to, say, https://github.com/BetterThanTomorrow/joyride/blob/master/examples/.joyride/scripts/sidecar_hello.cljs. Is the idea that joyride really is just for little tiny proof of concept extensions, not something that’s gonna have lots of pieces, or where it’s okay to have extensions depend on extensions? I see that the template README says that joyride/calva are dependencies (but, maybe, development dependencies, not hard dependencies for the extension itself?), and maybe joyride is just a way to hot test stuff that shadow’s building for final publication?

Hi @wcohen. I wouldn’t say that Joyride is only for tiny proof of concept. You can build about anything with it, and it can have many pieces and dependencies and whatever. The thing will be depending on Joyride, though, and there’s no distribution service. The template comes in when you want to build something that you want to share widely, and that does not depend on Joyride. It is a similar development workflow as with Joyride, but you won’t be modifying the window you are using, as with Joyride. You will be modifying a separate window; the Extension Development Host. I hope that clears things up a bit? Of course, Joyride is very good for prototyping. And a lot of the code will be portable to the extension template. (If you believe in keeping prototype code. 😃 )

this is a perfect explanation. i appreciate your patience -- i was just going in circles a little bit. i now have two tasks -- use joyride more widely besides having it installed for a year and only learning enough to turn off the friendly bugging on start screen, and give the template a shot too.

oh! one more question: this one could be 'distributed' on the marketplace but WOULD depend on joyride? https://blog.agical.se/en/posts/extend-vs-code-in-user-space--without-invented-restrictions/

Yeah. I think you can make the sidecar bundle Joyride. I haven’t tried it though. Would be cool if someone did!

Just a short personal experimentation to see Calva multi-repl in action.

There is actually one thing that I would like to hear some clarification: > Only one JVM process, and repl dev tools will be happier. I wonder what this means in practice. I mean pros and cons of starting both backend Clojure REPL and frontend Clojure REPL and then connect Calva to these two REPLs (two REPL sessions in Calva), compared to my old way that I start backend Clojure REPL, and frontend REPL, and just one connection from Calva to the frontend REPL, and access backend REPL via the frontend REPL (one REPL session in Calva). The first option sounds simpler.

I think it's more the case that if you have multiple (backend) JVM processes, you might eval one file to one JVM and another file to another JVM and so both REPLs would get out of sync?

Ah, ok. Thanks. So, if I have a Clojure/Clojurescript fullstack app, and I start a separate REPL for the backend (in terminal), and a separate REPL for the frontend (in terminal), and then two REPL sessions in Calva connecting to these two REPLs, this should be "a valid development decision"? 🙂

I'm not familiar with ClojureScript so I don't know the answer. I thought that if you use shadow-cljs, it has both backend (JVM) and frontend (JS) REPLs? I don't know what "a separate REPL for the frontend" would be, but having a JVM Clojure REPL and a JS ClojureScript REPL seems like a valid development decision.

I'd say having two JVM REPLs is fine if you know what you're doing and are careful 🙂 Caveat programmer, as soon often.

Thanks!

Let's wait if @pez provides some more light to this question. 😃

The ClojureScript REPL is a program running in the Clojure REPL. The way Calva has always solved ClojureScript work is to spawn off the ClojureScript REPL from the Clojure one. This way, there is only one JVM process and it supports both REPLs. They share macros and environment. For these reasons it is my recommendation that a fullstack Clojure+CLojureScript project uses this method. Calva will treat this as two REPL sessions, but still understand that they go together. So e.g. CLJC routing can be toggled between these two sessions. (Yet another reason to prefer this setup.) With the multi-session support you can also solve this by establishing one Clojure REPL connection for the backend, and then one Clojure + ClojureScript connection for the frontend. Leaving you with three sessions. This will use two JVM processes, and frontend and backend will not share macros and environment, and CLJC routing will become a bit tricky in certain situations (like if Clojure and ClojureScript code share source paths). It may be worth watching the announcement video in this light. https://youtu.be/36dTtyfa_OY (I venture into CLJC routing a tiny bit there.) The video may have been a bit tricky to spot in the announcement because this slack doesn’t provide YouTube previews.