I used to print those same structures without issues before, so I believe its something about the new version

(this is a quite large map)

Is this a regular clojure map or a custom type?

the root is a regular map, but nested inside it has other custom types

also volatiles and atoms

Mind trying https://github.com/djblue/portal/commit/b9de7ff4b53bac0ccbed753d209ce1aa9608dfc0 locally with the same data?

Instead of lazily pr-str'ing objects, which was causing other issues, I do it up front. I remembered to exclude atoms, but forgot about volatiles. Those tend to not print well, especially because they can have cycles. This is my best guess :thinking_face:

Should also be able to eval 👇 locally at the repl to try the fix

(in-ns 'portal.runtime)

(defn- to-object [buffer value tag rep]
  (if-not *session*
    (cson/tag buffer "remote" (pr-str value))
    (let [m (meta value)]
      (when (atom? value) (watch-atom value))
      (cson/tag
       buffer
       "object"
       (cond-> {:tag       tag
                :id        (value->id value)
                :type      (pr-str (type value))
                :protocols (cond-> #{}
                             (deref? value) (conj :IDeref))}
         m   (assoc :meta m)
         rep (assoc :rep rep)
         (not (deref? value))
         (assoc :pr-str (pr-str value)))))))

I can confirm it fixes after I run the patch in my REPL 🙂

Thanks, rolling out https://github.com/djblue/portal/actions/runs/3446503523 🙏

If you look in the devtools, it's probably complaining about popups. Might need to enable popups to get the UI open.

@djblue yep that was exactly it

I didn't read the docs closely enough 😅

Thanks

FYI https://cljdoc.org/d/djblue/portal/0.34.1/doc/guides/shadow-cljs is another way to run web taps

Oh perfect, thanks!

Will look at this

So would something like this allow me to tap values from the web page and display them in the Intellij plugin? :thinking_face:

Hm...I kind of got it working. I can tap values from my shadow cljs app, and they appear in intellij portal viewer, but now when I want to deref the selected portal value I have to do so from the clj repl? So values are getting serialized via transit from cljs to clj. Might be too much context switching to be worth it.

Seems only "pure data" values actually survive the trip as well, which the docs do mention.

The "in browser" setup is really cool tho. I put the portal setup code right in user.cljs and preloaded it from shadow, so now it auto-pops open the portal window when I start my app. And @p is easily accessible. Neat!!

Either works for me. Can you share some of the implementation?

Portal will try to set the default viewer on the metadata of a value based on what's selected in the UI https://github.com/djblue/portal/blob/master/src/portal/ui/commands.cljs#L504, but existing metadata takes precedence

Sure, I am doing something like this:

(tap>
  (with-meta
    {:foo 5}
    {`clojure.core.protocols/nav
     (fn [x _ _]
       (with-meta
         x
         {:portal.viewer/default :portal.viewer/pr-str}))}))

I would expect that the metadata of value returned from nav (in this case identity, but in my actual case, some derived data) would also work

I think this might be an edge case with propagating the viewer from the previous value 👌

Should be an easy fix