Yes, I always have such plans. Haven’t had the time to look in to it properly, though.

From exploring the VSCode extension api, it seems it would be coded in html/js/css and then invoked via a webview. I guess the data would have to be serialized to the webview, but that's probably OK as this already happens to some extent when it's printed to calva.output ?

I would probably use a TreeView for it. And then people can use Portal etc for fancier viewers.

I can't see a way to have tree view on a main editor, only on the sidebar…

Perhaps a tree view on the sidebar would be cool though. Something like this https://marketplace.visualstudio.com/items?itemName=ChaunceyKiwi.json-tree-view

Made an issue about this to track my thoughts: https://github.com/BetterThanTomorrow/calva/issues/1460

portal actually has its own vscode plugin that makes it a little easier to integrate. but i’m currently working on a way to make tools integration into calva easier for end-users, which would also make it possible to start portal with just one hotkey

The portal extension is Clojure only.

what do you mean by clojure only? it does work from cljs

Hmmm, last time I tried (which was a while ago) I couldn’t make it work with shadow-cljs, nor in a vanilla ClojureScript. I ran into problems adding a tap and @U1G869VNV said it was about portal.web not being supported in the extension. That might have changed, and I would be super if so. I want as much of Calva as possible to support both Clojure and ClojureScript, so this idea of mine of lacking support has so far stopped me from adding any specific portal support.

The portal extensions are only implemented for jvm but the code should be easy to port to cljs for node.js. Web cljs is always more tricky. For now I would advise using the https://github.com/djblue/portal#remote-api (which implies all values must be serializable as edn) and push values to a jvm/cljs hosted portal.

Given those constraints, the extension version of portal has most runtimes covered.

@U7PBP4UVA out of curiosity, what would you say is the biggest hurdle you have ran into? I'm always looking for opportunities for making portal easier to use 👌

For some reason I find the UI very difficult to scan. It might be something with the font size (which is quite big on my screen) or just lack of familiarity. Or it might be that I need to have the portal on my classpath... Idea: expose a remote portal HTTP api, that just accepts EDN data? Then anyone can write a simple http client function that just uses pr-str and POSTs that body to a plain http endpoint. No need to have any portal namespace in your actual application.

Something to note, a recent addition to portal is the ability to post edn/transit/json to an http endpoint :thumbsup: You can use the https://github.com/djblue/portal/blob/master/src/portal/client/jvm.clj#L15 or bring your own.

One thread per problem sounds good to me.

I'm afk. Without checking (or thinking much) I'd say make it return a promise and make the current callers await it.

that would be a lot of callers + those callers and so on. my thinking was wrong anyway, since getConfig gets called a lot and loading a file every time would be to slow. i’m doing it with a file watcher right now which works better + can be used to fix https://github.com/BetterThanTomorrow/calva/issues/1113

Sounds great.

are you sure there is such a thing as org.clojure/java.io? If you just want to access stuff in the http://clojure.java.io namespace, it’s bundled with clojure, no need to add it to your deps.

That worked. Thanks...