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".