Add support for the Portal Extension

[PEZ]

Now that there is a Portal Extension for VS Code, Clojure programmers can get an integrated inspector. There are some steps you can take to get this going manually, but we can make it butter smooth if we inject the dependencies and help with starting the Portal session.

[orestis]

I've been musing about this in various threads, so since I found an issue, I thought I'd write my two cents here, hope that's OK :)

I'm basically looking for a CIDER inspector alternative.

With the CIDER inspector, you can essentially drill down and explore a complex value directly within Emacs. AFAICT, CIDER will take the result of the previous nREPL evaluation and load it into the inspector. No configuration necessary.

I believe that Portal can take on this role within Calva, serving as the interactive explorer bit, without the user needing to do any configuration.

It will be a more limited experience than using Portal "natively" but a huge usability improvement. Here's what I think are the relevant steps:

• Whenever you connect to a REPL, Calva creates a persistent Portal server based on a separate environment (not hosted within the JVM or CLJS or anything inside the project, no extra runtime dependencies needed).
• Have Calva commands that can show the Portal UI if the tab is closed, exactly like the calva.output file.
• Have Calva commands that can send the last evaluation result to Portal for inspection.
• Optional: Have Calva commands that can evaluate + send the result to Portal
• Optional: Integrate the Portal extension or some version of it within Calva (no separate extension needed)

I hope I'm not misunderstanding how Portal is supposed to work. Notably, you lose the tap> functionality but that is a more advanced use case that is difficult to attain consistently across all environments, e.g. ClojureScript, Babashka etc.

[djblue]

I like the idea of having a basic setup that requires zero config on the users part aside from installing some extensions.

I think the easiest way to achieve this would be for portal to add a portal.submitEdn vs-code command which calva can execute with the edn string result of any eval, be it clj/cljs/bb.

A more decoupled option would be to have calva emit an eval result event that portal could listen to, but I'm not sure how vs-code plumbing works 🤔

As far as tap>, I wonder if nrepl should support it natively in the same way it does stdout/stderr kinda like prepl 🤔

[Cyrik]

Whenever you connect to a REPL, Calva creates a persistent Portal server based on a separate environment (not hosted within the JVM or CLJS or anything inside the project, no extra runtime dependencies needed).

That's a bit tricky, since we'd have to start a jvm that's running portal. It's possible (that's basically what we do for clojure-lsp) but it means that communication with that portal instance is harder. Having nothing extra running inside your repl is nice and probably a good end goal but I'm not sure it's currently worth the big investment needed. Automatically injecting the portal server into the repl would work for 80% of cases and only take a fraction of the dev time.

[orestis]

I think that the Portal VS Code extension opens a Node portal, no?

[Cyrik]

That's the portal client side. You still need a server that sends stuff over. That's why you still need the portal dependency in your repl, even if you have the portal extension.

[PEZ]

I think a CIDER inspector alternative is needed. Not sure it should be built using Portal, though. Maybe it should, but to me improved Portal support is about the full Portal experience. We should probably have a separate issue for tracking this CIDER inspector alternative need.

[orestis]

That's the portal client side. You still need a server that sends stuff over. That's why you still need the portal dependency in your repl, even if you have the portal extension.

If you have data as EDN, all you need is a HTTP request to send them over to Portal.

I have a couple of proof of concepts ready, yay for joyride, I will create a different issue to discuss them though, as per @PEZ wishes.