Fork me on GitHub
#portal
<
2022-04-23
>
djblue00:04:55

Added some docs around timbre for those interested in viewing their logs in portal. https://github.com/djblue/portal/tree/master/examples/timbre

❤️ 3
Luke Johnson03:04:47

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

awesome 1
🚀 1
djblue00:04:58

Also, thinking about writing some docs around utilizing the new test-report viewer, but I'm curious how most people develop their tests. At the repl? Or in a separate watch/test process? Editor supplied command?

seancorfield01:04:04

I hate the "watch" workflow with a pink and purple passion! I develop and run tests initially in the REPL from my editor (I never type into my REPL -- I have hot keys to run: the current tests, all tests in this namespace, all tests in what should be the companion test namespace to the current (`src`) namespace.

👍 1
nate05:04:01

I used to run the kaocha watcher more often, but now that I figured out how to use it in my repl I rarely run it in a separate process any more. I would like to hear more about what you have in the with-redefs stub code.

nate05:04:00

I'm interested in exploring these custom viewers. I need to see about sending my apps logs into portal with tap.

nate05:04:21

How easy is it to add a viewer on the same level as the tap or log viewer?

orestis08:04:09

I only use Kaocha from the command line after a long REPL session to make sure I didn't shadow any functions etc.

orestis12:04:27

I'm trying to setup my workflow (again!) with Portal and I managed to figure out how to open the portal VSCode extension and send code to it from CLJ: I added some calva commands that run a custom snippet that will eventually read .portal/vs-code.edn and submit results there via the HTTP api. Is this unnecessarily convoluted? I don't want to bring in portal as a JVM dependency, so the remote HTTP API is all I have to work with.

orestis12:04:48

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.

pez16:04:02

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?

pez16:04:01

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

djblue17:04:45

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

djblue17:04:27

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

djblue17:04:24

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

Lukas Domagala17:04:54

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

pez17:04:57

Like injecting. 😀

pez17:04:41

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.

❤️ 2
Lukas Domagala17:04:58

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

djblue17:04:52

@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?

Lukas Domagala17:04:06

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

👍 1
djblue17:04:14

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"}) 
Is this something the <!subteam^S03BGSAUPTQ|@calva-team> would want?

Lukas Domagala17:04:14

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

orestis19:04:20

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

orestis19:04:48

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

pez19:04:20

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.

pez19:04:49

@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?

2
wow 1
Jose Varela03:04:39

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 😂

metal 1
😂 1
👍 1
djblue04:04:55

@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 👌

orestis05:04:30

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?

djblue06:05:37

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

orestis07:05:41

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