Time travelling debugger

[Superpat]

Since most of the state of the ui is computed automatically from signals and that all imperative state changes can be recorded as a stack of events, I think it should be possible to implement some kind of event unwinding so we can travel back in time though user interactions.

The best place for this would probably be as an extension that can live in it's own tab in the dev tools.

I think the way to do this would be to intercept browser (like onClick et al) and server sent events and log them to a common log. If we can also log the related state before and after the event (so log the before / after data-store and whatever element is pointed to by the selector before and after) , we could show a diff of the changes and play the "opposite" of the event to unwind it.

Diffing the state changes should be relatively easy, unwinding them might be can of beans.

[delaneyj]

I'd want help but the idea of doing this via custom web element (probably with Lit.dev) would be awesome, could drop it on any page!

[Superpat]

We also need to be able to see what the current value of any data- attribute that takes an expression is.

[delaneyj]

For anyone wanting to track this there is an inspector branch where this work is happening

[gedw99]

This is a massive developer productivity enhancement.

I will try it out as soon.

Thankyou both for this !!!

[Superpat]

Alright the element_removal_inspection on github has the latest inspector code. All dom mutations are sent to the inspector and are registered as a separate version. The diff is logged in the event log and the snapshot is saved in the version object. A tree of Details allows you to explore the dom.

Things I need to do still:

• [x] Implement on hover functions in the dom viewer and the event log that highlight the element in the ui
• [ ] Make the reset button ask datastar for the current dom / store state instead of making them empty
• [ ] Go through the remaining plugins and check for logical places to put sendDatastarEvent
• [ ] Cleanup the actual code
• [ ] Improve the presentation
• [ ] Write a documentation page for the inspector
• [x] Allow the inspector to focus on only one part of the inspected dom (through a property)
• [ ] Embed the inspector in all example pages
• [ ] Write playwright tests that tests the inspector's behaviour on example pages
• [ ] There is no "search on ctrl-f" function in the devtools, so I need to add a way to search in the dom tree, since manually opening a large tree is cumbersome

I'm open to help with improving the presentation and embedding the inspector in all example pages.

[delaneyj]

Closing open with individual issues as planned