Fork me on GitHub
#portal
<
2024-07-29
>
chromalchemy18:07:45

What is the normal way to have multiple portal windows? Example: eval some data and have it up in a portal window (with chosen viewer), static, for future reference.. While I experimentally eval other data to another portal window, without disturbing the first. Then can update the first window, or dispose of it and spawn another (named) portal window, without disturing the first. Right now I can spawn multiple windows, and name them. But they all respond the same and all update on tap> . I am kind of fuzzy on Tap in general, and when it best practice to use an atom when opening the portal window..

chromalchemy18:07:32

How to tap or submit to only the desired window?

seancorfield19:07:31

You can use a different atom for each Portal window but tap> broadcasts to all registered tap listeners (and each Portal window is registered as a listener).

seancorfield19:07:11

Here's my Portal startup snippet: https://github.com/seancorfield/vscode-calva-setup/blob/develop/calva/config.edn#L57-L90 It uses a separate atom behind each Portal window and a custom submit that decides which atom to conj data into. In my case, I'm separating logging and middleware output into one atom and direct tap> calls into the other.

seancorfield19:07:40

If you have separate atoms and separate Portal windows, then when you want to inspect a particular value without disturbing your main window, you could conj it into the other window's atom (and each Portal instance can be deref'd to get the current selected value).

👍 1
chromalchemy19:07:52

Ok thanks. I will play with that. Was hoping for a less ceremonious way to view incremental results and keep them in my working memory. Like some of the basic affordance you get with clerk notebooks or dataflow canvases (but with more control of screen real-estate and tiling. Of course I can bundle up distinct partitions of data into one custom hiccup view, but thought maybe that was overkill. Btw. when I asked ai bots they kept insisting submit could simply take window name as an argument.. Oh well 😂

djblue01:07:46

Another option would be to use portal.api/inspect . You can call it at the repl to open a new instance of portal with a specific value. If the value is already in portal, you can select a value and call portal.api/inspect via the command palette, which has the additional benefit of using the same setting (launcher/theme) in the forked instance of the original instance.

djblue01:07:41

If you have multiple values in different places, you can multi-select those multiple values, put them into a vector via clojure.core/vector in the command palette then portal.api/inspect the resulting vector 👌

djblue01:07:11

(defn inspect-values
  "My Doc"
  {:command true}
  [& args]
  (portal.api/inspect (vec args)))

(portal.api/register! #'inspect-values)
If you wanted to automate those steps 👌

seancorfield02:07:02

Wow! inspect even works inside VS Code and opens a new Portal window inside the editor 🙂

💯 1
djblue02:07:58

Another feature that is out there but hasn't been documented is user provided shortcuts:

(defn inspect-values
  "My Doc"
  {:command true
   :shortcuts [#{"control" "shift" "i"}]}
  [& args]
  (portal.api/inspect (vec args)))

(portal.api/register! #'inspect-values)
I haven't thoroughly tested all the edge cases yet which is why it's not documented, but ☝️ will allow you to skip the command palette all together.

chromalchemy13:07:58

Nice. I did discover Inspect poking around yesterday before I read this!! Nice to hear about the conveniences. I am working through being mystified by the differences between tap>, tap-list, p/submit, custom submit fn, add-tap, inspect, open, open named instance, & open named instance with a named atom… But I think my basic workflow need was met by as simple as

(p/open {:value my-val})
Which is basically the same as (p/inspect my-val) This opens value in another window, that is not updated by the default submit fn (which is run during tap>) If I need to update window, then its
(def myportal (p/open {:value my-val})
(reset! myportal my-new-val)
Or i can create a custom submit fn that updates that instance on tap>. (even without referencing a named atom (tap list)?)

chromalchemy14:07:19

Can you add multiple submit fns to add-tap ?

seancorfield15:07:23

You can call add-tap multiple times. Then tap> will send it to all those functions. The tap system is global.

👍 1