day8 / re-frame-10x Goto Github PK

Pill selector
Saves to localstorage for persistence

Possible solutions:

• SASS (plugin)
• Garden

This is a prerequisite for #17, because the panel is currently picking up styles from its parent window, so we need to add a CSS-reset, which would be very unwieldy inline (though I suppose it's totally possible).

Edit: We will use clojure macro to read a CSS file (improving the current way, in which we are defining CSS in a string within cljs), and a separate issue is made to introduce CSS preprocessing!

• re-frame operation names in the form of [:idle :add-event] are incorrectly being interpreted as hiccup
• change to extract operation name only
• possible form for operation names:
  • ReagentInput
  • vector of keywords: [:idle :add-event]
  • keyword: :pieces

• Clicking trace names should add it as a filter parameter (e.g show-list-items under event names)
• Clicking the namespace of an operation should add that as a filter parameter (e.g. :sub/run under operations)

When re-frame-trace is hidden, it is just moved to the right hand edge of the screen, so it can smoothly animate on when it is unhidden. However if you change the size of the window (say by making it wider, or removing Chrome Devtools, the tracing window stays in it's fixed position. It would be good for it to reset it's position to the right hand side of the window whenever the viewport size changes.

This will probably require a PR to re-frame to add tracing books at the right part of the lifecycle.

Ideas

• have the time filter be a slider rather than a textbox, so you can see immediate feedback of how many events are passing the threshold you're adjusting.
• sort by time by clicking the header name

Same as #51, but for showing/hiding state

The string.split and string/includes? calls get very expensive when there are a large number of them. We should look into a cheaper way of doing this, perhaps by creating another Reagent function which returns a vector of the component hierarchy, rather than a string.

Show app-db in an explorable way (using cljs-devtools?)

• Automatically scroll to bottom when new info gets added
• Rotate around different screen edges
• Handle resizing better (using Facebook's Dom Mouse Move lib?)

This is better fixed by day8/re-frame#384

Currently, the extra info under each trace is the metadata.

See above: the metadata for the :event trace is empty because the event doesn't have metadata!

The :event traces extra info should instead show the dispatched event params, because this is something that people often println to check.

• when trying to resize window, mouse gets stuck and cannot leave resizing mode anymore

When you're scrolled to the bottom of the list, stay scrolled to the bottom as more events come in.

Currently, the dock is quite temperamental when resizing it, it would be good to handle this better.

Perhaps preloads could also be helpful here? The goal is to make it easy for people to add this in development, and still compile it out in production.

I'm not sure what/how we might use these, but they might be worth looking at a bit later in the summer. https://developers.google.com/web/updates/2017/06/user-centric-performance-metrics

Store user filters, e.t.c. in local storage so it persists between browser refreshes.

Based on my reading of the source, this seems to be web-focused. The tracing aspect of it, and monkey patching of Reagent, should be portable though, I think. Is there any plan to support React Native, or make this modular so it can be reused by someone looking to build a similar UI for React Native?

I see that re-frame.trace exists, and is used here, but the debugging documentation seems dated and doesn't mention it. I could really use this detailed tracing and would appreciate any suggestions.

When clicking a data structure, log it to the console. This steps around the problem with too much data being printed.

• steps to reproduce: click on data structure to print to console
• following error occurs for all operation type details except for event details:
  CLJS DevTools internal error: TypeError: Cannot use 'in' operator to search for 'constructor' in rx10

At the moment the node viewer is a bit unpredictable when things change. It needs someone to really get in to D3 and the Reagent lifecycle to understand what's going on.

https://github.com/Day8/re-frame-trace/blob/db2d11bcbc28eb2f39ea22aa6e8a71faccff7406/src/day8/re_frame/trace.cljs#L117

• for bigger applications, it is common to have similar event names across multiple namespaces
• that makes it harder to understand where event is being dispatched
• suggestion: display fully qualified namespace for events

When printing the tags for a trace, some of them may get very large. As a quick and dirty fix for #52 before that is completed, a bounded pprint function could be created. This would be the same as pprint, but when printing each top-level keys value, it would only print the first (say) 200 characters, and if the limit was hit, add a trailing elipsis.

This would be more efficient than our current implementation which pprints the entire datastructure, then trims the string. It would also be more useful as it would show at least part of each key, rather than one big value dominating the rest of the string.

Another option to do perhaps in conjunction with the idea above is to use fipp as it is much faster. We still want to not print the whole string though, as the string might get way too big.

As part of the filtering options, present a list of trace categories to be shown /hidden.

The list could be a checklist, or maybe some pills to be toggled.

Categories:

• re-frame internal
• reagent rendering
• application events
• subscriptions
• ???

some things that need to be implemented to polish the filter functionality:

for traces filtered by milliseconds:

• at the moment, it is possible to enter several slower-than filters
  • either disable adding a new slower-than filter if another one is already in the list
  • or apply only filter that has been entered last

for traces filtered by words:

• prevent adding duplicate search queries

The trace panel picks up the CSS of its host page. The solution will probably look like: somehow resetting the CSS to user-agent defaults, and then define the trace panel styles on top of that.

Currently, the filter options scroll away with the list. They should be pinned, so you can always see what's being filtered. Like so:

Allow users to save filter sets, and choose filter defaults for when the panel first opens.

We have no idea what this might look like UI-wise, so this is a super nice-to-have-in-the-future type of task.

We ran into a couple interesting questions over the last weeks where the answer was "source-paths":

1. How does re-frame-trace build?? I don't see anything in the project.clj that looks like it will build.

   Answer: when you add a path to the :source-paths of the test project used to develop the trace panel against, figwheel of the test project will know to watch and build it too! So cool!

2. Why are changes in my local re-frame repo reflected in the example project? Shouldn't it be pulling from clojars?

   Answer: It's because if you are using the example project that lives in the re-frame repo, it has the local re-frame repo in the :source-paths! (as "../../src").

This might be helpful in the readme! I'm sure this is something many clojure developers are familiar with, but I myself learned it during the course of this project, so others might benefit too.

To reflect current status. Maybe also include a gif? http://gifbrewery.com

One of the challenges with this tool is effectively viewing the data. Oftentimes dispatched events are very large, and it is not efficient or useful to pretty print it all to a string at once. Having a live data structure browser that could be used to progressively unpack event tags, and to view app-db would be a really really great feature.

Dirac has a really great implementation of this, and re-frisk also has a data browser (but it's not quite as fully featured as Dirac's).

https://docs.google.com/document/d/1FTascZXT9cxfetuPRT2eXPQKXui4nWFivUnS_335T3U/preview

http://www.mattzeunert.com/2016/02/19/custom-chrome-devtools-object-formatters.html
https://gist.github.com/mattzeunert/a9a5aebc736f9f30e53f

Originally, the LESS and CSS files were in src/day8/re_frame/trace/css and src/day8/re_frame/trace/less.

Then, they were both moved to resources/day8/re_frame/trace because it's more proper naming convention to places styles into the resources folder.

However, now the host project can't find the CSS, because we gave instructions to change the source-paths to look like this:

:source-paths ["src" "../../src" "checkouts/re-frame-trace/src"]

and resources sits outside of this.

Which is a preferable fix?

1. adding "checkouts/re-frame-trace/resources" to :source-paths
2. moving the LESS and CSS files back into src/day8/re_frame/trace

Actionable item: update the README and/or file locations to reflect the decision made here!

This is in the node view.

I noticed this on one of our internal projects:

This will allow you to grab it later on when re-rendering it if you're developing re-frame-trace. The id should be sufficiently unique to be unlikely to collide with anything else.

https://facebook.github.io/react/blog/2016/11/16/react-v15.4.0.html#profiling-components-with-chrome-timeline
https://developer.mozilla.org/en-US/docs/Web/API/User_Timing_API

Text, integers, and booleans should be editable in the app-state browser tab!

Filtering is quite crude at the moment, it would be good to have better mechanisms for filtering.

Epochs are defined as being the bounds between an event being fired, and all subsequent events, db updates, subscriptions, and renders being run. This is inherently a little bit of a fuzzy concept, as there may be events added to the re-frame event queue by async network activity which becomes part of the epoch, even though it is logically separate. For developing and debugging purposes to show the separation of events this is good enough.

How do we know when we are in a new epoch? How do we know when it is finished? Just based on events? Should there be something fired at the end of the render?

We also want to show in the trace view the bounds of each epoch.

Helps with #75.

Isolating trace panel and host project styles is pretty gnarly at this juncture. We have two problems:

1. prevent trace panel styles from interfering with the host project
2. prevent host project styles from interfering with the trace panel

Previously, we were addressing 1) in a painful way, which is manually writing out the name-spacing CSS class every single time we define a new style. Preprocessing makes this much much nicer.

Preprocessing doesn't address 2), but it would certainly make it easier to do a more complete job of making sure we properly overwrite all host panel CSS.

LESS or SASS?

I was looking for the best way to use SASS in clojure projects, and it seems most of them require you to have Ruby installed, or at least their readmes claim as much. I didn't want to deal with that kind of overhead.

• https://github.com/tuhlmann/lein-sass needs Ruby
• https://github.com/vladh/lein-sassy also needs Ruby

LESS did not require the developer to install Ruby, so I am going with LESS.

I also looked at re-frame-template for inspiration and noticed SASS option was removed a couple weeks ago due to compatibility issues: day8/re-frame-template@5ee0540

That aside, LESS is less draconian and so it's more friendly to develop with for people who have just a bit of experience with CSS, so figured it wasn't that much of a loss.

Be able to help users answer the question "Why did that sub fire?". We have some of the information from the hierarchy by chained subs (although not all data dependencies go through chained subs).