Handling things like [(atom {:a 1})] further?

[sogaiu]

Assuming a fresh setup for the standard example, (tap> [(atom {:a 1})]) leads to the following in the Entries pane:

id: 0
value: [#object [cljs.core.Atom {:val {:a 1}}]]

Clicking on the associated line in the Entries pane leads to the following in the Current pane:

idx: 0
value: #object [cljs.core.Atom {:val {:a 1}}]

Clicking on the associated line in the Current pane leads to the following in the Next pane:

#object [cljs.core.Atom {:val {:a 1}}]

At this point, it doesn't currently appear possible with the current UI to "examine" the latest value any further. Is that correct?

---

As an experiment, I modified the edn pane to support being clicked (very un-REBL, but yet, very rebel ;) ):

(defnc EdnView [{:keys [data nav] :as props}]
  [:div [:code {:on-click (fn [v] (nav data nil v))}
         (prn-str data)]])

and punk/core.cljc's :nav reg-event-fx to be:

(f/reg-event-fx
 frame :nav
 []
 (fn [{:keys [db]} [_ idx k v]]
   (let [x (get-in db [:entries idx])
         dx (datafy x)
         v' (get dx k)
         x' (nav dx k v')
         ;; store this nav'd value in db for reference later
         db' (update db :entries conj x')
         idx' (count (:entries db))
         dx' (datafy x')]
     {:db db'
      :emit [:nav idx {:value dx'
                       :meta (meta dx')
                       :idx idx'}]})))

based on a reading of seancorfield's Datafy / Nav blog post:

Relating this back to REBL, it works by taking some arbitrary value produced in the REPL and converting it to data (via datafy) so that it can be displayed in the UI. With any part of that data highlighted you can “drill down”, at which point REBL calls nav to perform the (potentially lazy, complex) navigation and then converts that to data (via datafy) and displays that as the next “level” of data. Given an associative data representation, it does (get coll k) first to get v, and then it calls (nav coll k v) to allow the underlying navigation to return an updated value.

Ignoring UI/UX issues for the moment, this at least allowed further examination, i.e. clicking on the Next pane lead to the Current pane being filled in as:

idx: 0
value: {:a 1}

(and from there futher exploration was also possible.)

May be this is all moot with punk2?

[sogaiu]

As a follow-on experiment, in addition to the changes mentioned above, tried the following at the REPL:

  (in-ns 'clojure.core)
  (defmethod print-method clojure.lang.Var [o ^Writer w]
    (print-tagged-object o (str o) w))

This allowed sending vars and processing them in punk's UI (only tested in the electron app).

With this modification, using results processed from Stuart Halloway's reflector (https://github.com/stuarthalloway/reflector) worked in punk's UI -- e.g. browsing var-related info (not the same as what's provided in REBL for vars "natively").

[sogaiu]

With just the modifications in the first post (view and reg-event-fx), tried using seancorfield's next.jdbc, in particular what was described at (https://github.com/seancorfield/next-jdbc/blob/master/doc/datafy-nav-and-schema.md#user-content-identifying-foreign-keys):

By default, next.jdbc assumes that a column named id or _id is a foreign key into a table called with a primary key called id. As an example, if you have a table address which has columns id (the primary key), name, email, etc, and a table contact which has various columns including addressid, then if you retrieve a result set based on contact, call datafy on it and then "drill down" into the columns, when (nav row :contact/addressid v) is called (where v is the value of that column in that row) next.jdbc's implementation of nav will fetch a single row from the address table, identified by id matching v.

• That is, first created two tables (address and contact), where one table has a column with values from another (here, contact having address_id) and populated them with some appropriate data.
• Then sent the results of querying for everything in the contact table to punk's UI.
• Subsequently, punk's UI was capable of navigating to a result from the contact table that contained a reference to something in the address table.
• Finally it was able to go from there to a corresponding row from the address table.

It was a bit odd having to click on a number (representing a foreign key) in the Next pane, but it was neat to see it work out :)