Is the idea to use the value at the repl later or that you want to visually compare it to another?

You can pull a selected value back into the repl via derefing the portal atom which is returned from portal.api/open

(def p (portal.api/open))
;; select value in ui
(def selected @p)

(ns user
  (:require [portal.api :as p]))

(def values (atom []))

(defn push [& args]
  (swap! values into args))

(p/register! #'push)

I have tried to write some fairly fancy code to ensure that the most recently tap>'d value always ends up as the most recent value in Portal with any middleware tap>'d values below it, so that I can programmatically get at that value from my editor. I don't want to have to interact with the Portal UI in general to select anything. I want to drive it all from my editor. And that requires a degree of predictability of where values are in the UI in order to get at them programmatically. I pretty much never want to interact with some arbitrary result produced by evaluation middleware -- but I want to drive Portal's UI from my editor to cause interactions with the most recent interesting value. In many ways, it would be ideal for me to have middleware eval output go into a separate panel in Portal and have just my direct tap> values go into the regular panel so the most recent was always what I explicitly tap>'d. I want the Portal UI to be more "drivable" by code, overall :)

TL;DR: it's not so much about having a specific value in Portal accessible to the program, as having the program be able to drive the UI in Portal around a specific value.

For example, I commonly want to cycle through viewers programmatically for the "most recently tap>'d value" but I want to ignore any middleware-produced data for that. Seeing that output is useful, and having the option to switch to the Portal UI and interact with it is nice -- and sometimes necessary -- but not my primary workflow when debugging. I have logging wired up to tap> into Portal, for example, and I already have a hot key set up to toggle that wiring on and off so I can eval a specific piece of code and not have logging clutter up Portal's UI, even tho' in general logging is useful. And I may end up doing something similar for middleware output, but it's still a pain to have to do this manually around specific evaluations. Having two separate sections in the UI for this would be my ideal choice: and then I could have logging and middleware go to the "secondary" panel and my explicit tap> results go to the "primary" panel -- and then programmatically interact with just that primary panel. Being able to start multiple VS Code launcher/viewer instances from a single JVM might solve this too -- not sure if that's possible?

@U04V70XH6 would something like the following fit your workflow better?

(def tap-list (atom (list)))
(def eval-list (atom (list)))

(defn submit [value]
  (if (:portal.nrepl/eval value)
    (swap! eval-list conj value)
    (swap! tap-list conj value)))

(add-tap submit)

(portal.api/open
 {:window-title "tap-list"
  :value tap-list})
(portal.api/open
 {:window-title "eval-list"
  :value eval-list})

Can I have two VS Code windows open?

Yeah, you should be able to have multiple.

That's cool... let me try that...

And portal can be opened with any value, including atoms you can drive

The tap-list that is loaded into portal by default is:

(defonce ^:private tap-list
  (atom (with-meta (list)
          {:portal.viewer/default :portal.viewer/inspector})))

My setup is somewhat complicated by having my Portal start code be part of my Calva custom REPL snippets with logging wired up elsewhere but let me spend an hour playing with this... I had no idea I could manage my own tap list like that...

What will the portal.api/* functions do when there are multiple instances?

I think they do a broadcast, they should have an arity which includes passing in a specific instance

And that "specific instance" is what comes back from open?

close and clear are really the only ones that care

Well, I have a lot of this sort of stuff:

{:name "Portal Viewer"
   :key "0"
   :snippet (portal.api/eval-str
             (str
              '(let [state portal.ui.state/state]
                 (-> (portal.ui.commands/select-none state)
                     (.then #(portal.ui.commands/select-child state))
                     (.then #(portal.ui.commands/select-child state))
                     (.then #(portal.ui.commands/select-next-viewer state))
                     (.then #(portal.ui.commands/select-none state))))))}

eval-str also takes an instance 👌

Ah, it accepts portal too... OK, this is looking very promising 🙂

Ohh, also I added {:await true} to eval-str so you can block on promises if you still wanted to use something like that

Nice, thanks.

(portal.api/eval-str portal "(.resolve js/Promise :hi)" {:await true}) => :hi

OMG! THIS IS SO AWESOME!! This dramatically simplifies my Portal setup and provides so much more value!!!

Interesting tap>'d values on top; middleware output below:

That's looking very nice 👌 I think we have portal setup similarly for logging / taps at work

Sorry I didn't mention it earlier

https://cljdoc.org/d/djblue/portal/0.37.1/doc/guides/custom-tap-list for some other ideas

The "danger" of an infinitely flexible toolchain is that you can almost never know what is possible 🙂

I think the upcoming notebook updates are gonna make things even more flexible / fun for vscode users

https://github.com/seancorfield/vscode-calva-setup/commit/d379e6b202dc44404a82d3eb44ee8ab8d9bbd025 -- so much simplification 🙂

Ohh, if your eval-str commands return :portal.api/ignore the nrepl middleware will not tap them 👌

Also, the code does look much nicer

Good to know about :portal.api/ignore (allow that seems a strange value for the nREPL middleware to care about -- I'm surprised it isn't :portal.nrepl/ignore 🙂 )

That would be better, but I have some custom socket repl based tooling that I use that needs the same behavior so I use that keyword for both

I could use both if it makes more sense :thinking_face:

I updated my config.edn to use that. It caught another case I wasn't handling, so that's helpful.

It's really exciting seeing the evolution of how you utilize Portal in your workflow so thanks for taking the time to share your experiences ❤️

I need to write another blog entry 🙂