An Aspirational Wishlist

[mike-thompson-day8]

The Bullet List

A central wish list (individual items will ultimately become a separate issue):

• what changes/deltas to app-db occurred. How about to each of the nominated paths. Can I switch backwards and forwards to see the value at a path and the delta?
• which subscriptions ran (show deltas too). Which subscriptions did not run.
• in the trace show me markers for begin-annimation-frame and end-animation-frame
• a high level summary: how long did it take, how many subscription handlers ran, how many animation frames were used, etc.
• the event (may be too big to render?)
• how many coeffects handlers ran? Which ones?
• what event handler ran? Data inputs/outputs?
• what effects?
• what effects handlers ran?
• which views re-rendered?
• how to better process and display "intra" epoch trace - mouse-over rendering etc.
• add a "RePlay" button to the tabs layer Add new "replay" button  #155. See also these docs
• Provide a way too make trace data available in the figwheel REPL for further experimentation. Something like scope-capture. Click button to copy an expression which gives you access to the data that you can take to the REPL.
• What hiccup did views return? Deltas to last time? Careful of functions.
• User should be told if any views ran unnecessarily? Same hiccup as last time?
• better filtering in some tabs. Eg. events and subscriptions.
• User should be told if bad subscription "patterns" are detected. Detect and alert users on unusual subscription run patterns #148
• User should see if an exception occured during the epoch? Big red bar to tell me to look in js/console?
• User should be able to easily navigate to handler source code (events, subscriptions, effects, interceptors). No idea how to do this other than with macros - booo - perhaps we can just write stacktraces into js/console so they can be source mapped. Click a button in the re-frame-10x to see stacktraces put into the dashboard?
• As above, user should easily find out from where an event was dispatch-ed. Source code coordinates.
• the programmer should be able to produce trace themselves and have it appear in re-frame-trace. See Allow 3rd party trace #149.
• show a graph of subs. How data flows from app-db up the tree to the views. Use cytoscape.js?
• show a graph of views. Will be big. Probably too big. Too much noise because of the VBoxes and HBoexs of this world. But if we exclude HBox etc. there will be discontinuities.
• better interaction with the chrome profile API. See Make use of new Chrome performance measurement APIs? #28
• buttons to save app-db to local store and then restore. Useful if you have to restart the application and you want to immediately get back into the right state. Add proof of concept for saving/restoring app-db #112
• make timings more accurate by repeating an event 50 times and averaging. See Optional, More Accurate Timing Through Repetition #113

UI Mocks

We use figma, which is not very good for OSS, sorry, but its is the tool we know.

Here are the mocks: https://www.figma.com/file/EXTcBzsMoORAOb4dd8GFsgko/re-frame-trace-mock

Todo:

• mock a better events panel
• mock the "views" panel
• mock a better way of viewing the execution chain for "interceptors".

[mike-thompson-day8]

Update on the wishlist item "user should easily find out from where an event was dispatch-ed. Source code coordinates.":

The data substrate shipped upstream in re-frame 1.4.6+ via the new re-frame.core-instrumented namespace (renamed from re-frame.macros in 1.4.7). It's a drop-in macro mirror of re-frame.core that captures call-site {:file :line} at every dispatch / dispatch-sync / subscribe / reg-event-* / reg-sub site and attaches it as event metadata under the :re-frame/source key. No production overhead — DCE strips it under goog.DEBUG=false.

To opt in, users swap their require:

;; before — no source meta
(:require [re-frame.core :as rf])

;; after — call-site {:file :line} on every dispatch
(:require [re-frame.core-instrumented :as rf])

Once swapped, every dispatched event carries its dispatch site automatically. See day8/re-frame@1.4.6+ for the full surface and DCE notes.

Status in 10x itself: the upstream data is now reachable but 10x's panels don't yet read :re-frame/source to render dispatch coordinates in the event-history or epoch detail views. The capability is unblocked; surfacing it is a separate follow-up. (For reference, day8/re-frame-pair consumes :re-frame/source in its coerce-epoch and surfaces it on every epoch — that's a working integration template if a 10x consumer wants to land the panel-side change.)

[mike-thompson-day8]

Update on the wishlist item "better filtering in some tabs. Eg. events and subscriptions.":

This shipped across three places:

• Event history — regex filter search box at src/day8/re_frame_10x/navigation/views.cljs:240 (epoch-filtering). User input is cast via re-pattern; matches are filtered in navigation/epochs/subs.cljs:25 (::events-by-id). Clear button visible only when input is non-empty. (This is the regex filter @superstructor specified in the 2022 comment thread on #199; referenced here as that's where it was originally requested.)

• Subs panel — "filter subs" search box at src/day8/re_frame_10x/panels/subs/views.cljs:475 (filter-section). ::subs.events/set-filter writes the filter string; ::displayed-subs (panels/subs/subs.cljs:137) filters via string/includes? on path and id when the filter-str is non-empty.

• Traces tab — composable queries at src/day8/re_frame_10x/panels/traces/views.cljs:138. Beyond a plain text filter, the user picks a query type (contains / doesn't contain / slower than) and adds multiple queries. More sophisticated than the string-include or regex filters elsewhere.

Net: every tab the wishlist named has user-driven filtering today, with each tab's filter shape suited to its data (regex for event history, string-includes on path/id for subs, composable typed queries for the trace stream).