TimeTravel is an Elixir library (& browser extension) that allows one to record and replay the interactions in a LiveView application - enabling easy debugging of the LiveView socket state
A video demonstration is available on GitHub
What’s the problem?
When developing, your LiveView might not behave how you expect it to. If you’re anything like me, this means you drop several IO.inspect or dbg calls in your LiveView and scroll through terminal output to see the state of the assigns as they change through the life of your LiveView. But there’s a better way!
TimeTravel enables easier debugging of a LiveView because all assigns are visible in the viewing pane and one can replay interactions to see how assigns change over time - if you put an IO.inspect in the wrong event handler, no problem!
It also allows one to rewind the LiveView to a specific point-in-time and replay different interactions from a known good state. This is helpful if you are designing, for example, an online checkout page and need to test several different failure modes without replaying the entire interaction on each page refresh.
TimeTravel was inspired by Elm Reactor, rr-project, and Vue Devtools - The post on Elm Reactor is where I borrowed the online checkout page example from 
How does it work?
TimeTravel attaches to the telemetry events emitted by Phoenix LiveView and stores the socket state at the time of each event. The browser extension allows one to move the slider back and forth to inspect the socket state at the time of each event.
Demo, Usage, and Video
The TimeTravel Demo application is available on GitHub
If you don’t want to clone and run the demo application a video demonstration is available on GitHub
In the video, as items are added and removed from the list, the socket state inspector in the DevTools pane updates the items assign that’s easily visible. As the event slider is dragged back and forth, the socket assigns (& DevTools pane) are set to the values they held when that event was fired.
If you would like to try TimeTravel in your own LiveView application, follow the installation instructions on GitHub. Please report any issues running the application here
TimeTravel is, at this stage, more of a proof-of-concept than a fully functioning library and has all sorts of issues, bugs to iron out, and tests to write. Below is a list of known issues:
Known Issues
- No graceful restore if LiveView crashes
- If your LiveView crashes and re-mounts the event slider will only work for events that were fired after the remount. This is generally considered undesirable behavior for a debugger and will be addressed in the future
- Chrome extension manifest is V2
- Because the extension has a V2 manifest, it is unable to be distributed in the Chrome Web Store. If you have advice on how best to turn a V2 manifest into a V3 manifest, please let me know. Pull Requests are, of course, always welcome
- Because the extension has a V2 manifest, it is unable to be distributed in the Chrome Web Store. If you have advice on how best to turn a V2 manifest into a V3 manifest, please let me know. Pull Requests are, of course, always welcome
- LiveComponent telemetry not supported
- This is possible, I just haven’t yet implemented it
- LiveView does not have a
handle_infotelemetry attachment- This is by design and I’ll need to think on how best to instrument
handle_infofor LiveViews
- This is by design and I’ll need to think on how best to instrument
- Must subscribe to PubSub in
mount/3callback to receive events -
handle_infocallbacks must be copied/pasted into LiveViews to debug them- This, like the PubSub issue, is really annoying. If there is a way to inject the
handle_infocallbacks into each LiveView, I’m all ears. For PubSub, I can probablycastto each GenServer that has a LiveView pid
- This, like the PubSub issue, is really annoying. If there is a way to inject the
- Memory usage is high
- Storing the socket state for every event gets large. As of now there is no code that deletes socket state (but socket state is only stored if the DevTools pane is open). Restart the server or run
GenServer.cast(TimeTravel.Jumper, :reset)from IEx - Similarly for the browser extension, the
chrome.runtime.storageAPI will hit its limit of 5MB fairly regularly. Use the “Clear Storage” button in the DevTools pane if you begin to see console errors.
- Storing the socket state for every event gets large. As of now there is no code that deletes socket state (but socket state is only stored if the DevTools pane is open). Restart the server or run
- Flash assigns are not supported at this time
- Flash is a special assign and will need more work to support correctly
Other minutiae
My ideal implementation of this would store a diff snapshot every time the /live socket receives an update. This would allow for any kind of update from LiveView → DOM to be inspected regardless of whether or not it’s supported by Telemetry. I attempted to go down this road for about seven minutes before I decided I don’t want to go spelunking in the LiveView internals
Links 'n More
- Time Travel Github Repo
- Time Travel on hex.pm
- Time Travel Demo App Repo
- Time Travel Browser Extension Repo
- Time Travel Made Easy - Elm Lang
- rr-project
- Vue Devtools
Thank you for reading
