Awesome! I will be making changes to add those sweet new stacktraces!

I still can't figure out how to do this from CLJS though - I can obviously use fetch or some other browser API to send commands to Portal, but I've no clue on how I can read .portal/vs-code.edn from a browser context.

Remind me again what stops portal from running integrated in the editor for ClojureScript? People in the <!subteam^S03BGSAUPTQ|@calva-team> asked me and I realized I couldn’t answer. Solving that would also solve this thing, I take it?

Oh, sorry, I somehow managed to think it was @U1G869VNV who answered in this thread. 😂

@U7PBP4UVA This is a use case I hadn't considered but is still valid :thumbsup:

What I do for cljs is open the portal with a fixed port number, so then I don't need to coordinate the port.

But since you can't specify the port with the vs-code extension, not sure :thinking_face:

Not sure if integrated would help here. The problem is that portal needs something inside the runtime. If you don't want to add that dependency calva can't help. That would be like not injecting cider-nrepl

Like injecting. 😀

We have a branch of Calva where the portal dependency is added to the jack-in command line if the portal extension is installed and active. I’ve put it on ice until I understand if ClojureScript can get the same nice support as Clojure has. But anyway, portal is important enough to get special treatment from Calva.

Injection works. I just have it as extra :dev dependency, together with some other stuff

@U02EMBDU2JU, how do you coordinate the server port to a cljs client such that web taps can be sent to the ui hosted by the extension?

Sorry I meant for clojure. Didn't use cljs for a bit now

I think an interesting solution to this problem would be having the portal extension provide the data to calva, perhaps by adding a notion of a repl context, and have the info propagated into the evaluation environment. 1. The portal extension calls a calva api to register context info {:host "localhost" :port 12345} 2. The user evaluates some code, and the registered extension contexts get propagated {:portal {:port ...} :other-extensions ...} 3. The user can leverage said context in their code via:

(js/fetch (str "http://"
               (get-in *calva* [:portal :host])
               ":"
               (get-in *calva* [:portal :port]))
          {:body "hello, world"}) 

My mind is blanking right now, need to eat and sleep 😅 But I’ll try to give some feedback tomorrow. Maybe @U0ETXRFEW has a better grasp on the cljs side anyway

I would be happy if I could provide the vscode-integrated portal a fixed port.

Again, I don't want the portal dependency in my main project classpath - in principle :)

We're going to give you the option to do that thing easy, anyway 😃 But yes, it is an optional feature in the spike branch for this.

@U1G869VNV would an API where Calva makes the repl connection available, say via en eval(some-code) function, solve things from the portal end of things?

oof out of the box integration between portal and calva would be killer… i know yall know that just wanted to cheer from the sidelines 😂

@U7PBP4UVA, not sure if you've solved this issue yet, but if you are already reading the .portal/vs-code.edn file, you can also inject it into your index.html as a global js variable 👌

Oof - not sure if my colleagues will appreciate that 😅 perhaps a .portal/config.edn with a static port would sidestep a lot of these issues?

@U7PBP4UVA Would something like https://github.com/djblue/portal/pull/124 work for your use case?

I think that's a necessary step @U1G869VNV - I've commented on a Calva issue, explaining my desired workflow: https://github.com/BetterThanTomorrow/calva/issues/1327#issuecomment-1120367038