You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 5, 2023. It is now read-only.
Let's say an application wants to have something like the Elm Debugger (i.e. display a list of messages, allow to import/export this list, and be able to go backwards and forwards having the app display the state).
The debugger UI would have to have it's own state and messages
Tracking of the incoming application messages should happen in that debugging state
Replay of a list of messages against some starting state should ignore commands - if the commands had any effect on the state, they did this be emitting other messages. These messages will be already in our message list.
The list of messages can become a tree if the user rewinds the state and takes a new path
In replay mode, some messages may have to be filtered (e.g. clock ticks, or messages from a SSE EventSource)
One approach would be
Have two Bonsais, one for the debugger, one for the application under debug
When the debug UI is used, the application bonsai is put in "Replay Mode". It ignores any messages it receives in the normal way, can only replay messages under control of the debugger
If the users wants to start working normally again, he must leave replay mode. This will either remove the rest of the message list, or add a new branch to the message tree