Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: Debugging Tools #52

Closed
awkay opened this issue Nov 3, 2017 · 9 comments
Closed

Enhancement: Debugging Tools #52

awkay opened this issue Nov 3, 2017 · 9 comments

Comments

@awkay
Copy link
Member

awkay commented Nov 3, 2017

I've been wanting to build something for a long time that would give you a debug overlay in develop mode. It really would not be that hard to make. Basically a Fulcro app that is pre-packaged in the Fulcro resources that you can embed in your development HTML and link to your running app. All sorts of cool stuff possible. Table browser, state watches, etc.

@currentoor
Copy link
Contributor

I'd like to help with this. To make sure I understand what you mean.

Table Browser
Just a pretty printed view of a particular table? Or a way to grab a particular entity in the table by id?

State Watches
What would this be? I'm not sure what you mean.

Here's some thing I might find useful. Thoughts?

Query Tree
A way to see the current root level query of your application.

@awkay
Copy link
Member Author

awkay commented Nov 7, 2017

Hey great!

So, the state atom can have watches on it. I was thinking that the debug tools could hook into that in order to know when the application changed state and update any view it has open.

In terms of a data/table browser. It could show the keys in the root node...perhaps detect tables as maps whose values are maps? Maybe just an ident input? Then yes, a pretty formatted view of content, with hyperlinked idents? I'm open to ideas.

Would the root-level query be that useful? It is often a huge unwieldy thing. I had also thought of leveraging the *instrument* functionality to augment mounted components with a click sensor that could focus dev tools on that component's query and current props.

Technically, if the debug tools have access to the fulcro app, then it also has access to the reconciler and indexer, meaning that it can find any component on the screen by ident, property, or defui class. So it would be possible to find the components on screen for a given table entry and "overlay" an info pane of some sort showing the query of that component, the props it received, and the props that are actually in the database.

I was also thinking that we don't have to package anything in resources...when you're in dev mode we can just have ppl declare something in their dev user namespace and hook it to their app. We could also auto-insert a node in the page's DOM so they wouldn't have to do anything to their HTML.

@wilkerlucio
Copy link
Collaborator

wilkerlucio commented Nov 20, 2017

I've been doing some work around this as well, not ready to share yet (but will this week). The idea was to start with something like re-trace (https://github.com/Day8/re-frame-trace). The initial focus was to have a database explorer, with watch capabilities, triggered by a keyboard shortcut that floats on screen, like this:

fultrace

The selector on the bottom allows for switching apps, so you can track different apps same time (useful for devcards, or if you have more than one mounted fulcro app in general).

For the next tabs:

  • Element - the idea is to have something like an element picker, like the one chrome does, that will display information about the element like Query, current props...
  • Network - I'm working on this now, a network history with requests/responses
  • Transactions - The TX log for the application, can be handled by hooking on reconciler tx-log
  • OgE - Integrate OgE (https://wilkerlucio.github.io/oge/) to try out queries from the inspector.

I'm sorry I did kind run over on this one, I'm just needing it quickly. Help will be appreciated, I should be releasing this code soon. Thanks.

@wilkerlucio
Copy link
Collaborator

History can also be integrated into the DB tab, I have a vague idea for a UI that you could use to navigate to past versions, the watches and expanded the state of the DB can be kept during state changes (as they are already).

@awkay
Copy link
Member Author

awkay commented Nov 20, 2017

@wilkerlucio Be sure to look at the new history.cljc...there are specs about what is in it. The tx history is already there, as are the return merge's from the server interations. Oh, and timestamps, and a db-before/db-after which would be useful for showing diffs.

@wilkerlucio
Copy link
Collaborator

@awkay sure, it will probably have more than one version, I need this for the current Fulcro, but will be nice to read from an integrated place. That said, the integration layer is pretty thin, shouldn't be hard to switch the integration points.

@awkay
Copy link
Member Author

awkay commented Nov 20, 2017

I'm adding a way to register tools with Fulcro in a global sense so that apps start they can inform tools. I also want to expand the information that can be given to merge to include data about why the merge was done (e.g. network response).

@currentoor
Copy link
Contributor

@wilkerlucio no need to apologize 😄. I just started and you're much farther along.

After pushing up your code, I can see if there's something for me to do on this. Otherwise, I'm sure there's other stuff I can work on in Fulcro.

Cheers

@awkay awkay assigned awkay, wilkerlucio and currentoor and unassigned awkay Nov 22, 2017
@awkay
Copy link
Member Author

awkay commented Nov 22, 2017

since this is now on clojars, I'm going to let the issues in fulcro-inspect server the purpose for further development.

@awkay awkay closed this as completed Nov 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants