Implemented time travel, without any good rules.

[mrozbarry]

You're telling me you build a time machine...from a Delorean?

Note

• This definitely isn't ready for a merge yet, but want to open this PR for discussion.

What

• Adds time travel to the debugger

To do

• [x] Decide on how we deal with time travel history - when we hit an old action, do we no-op all actions until the user selects the latest action? Do we enable multiple histories, and if so, what does the data and UI look like for that? We have some discussion on #1, but no real answer yet.

Ticket

• Closes #1

GIF

[Mytrill]

I have been thinking about the rewrite state issue, and I may have a simple, yet powerful idea:

• we create the action actions.$__SET_STATE before we enhance the actions (so that it gets enhanced too)
• in the list of actions on the left pane, when we have a call to actions.$__SET_STATE we name it "time travel" or something

This way, time travelling is nothing more than a regular action, and the user see their time travels all in one timeline and can go back over and over.

What do you think?

[mrozbarry]

I've got some mixed feelings. So I like the idea that we essentially make time travel history, but it also has the potential to grow the history, and big arrays in js usually mean poorer performance. You do, however, support grouping, so maybe that will minimize a lot of it.

Another option for writing different histories is to use your run-instances concept. If you time travel and start editing, the debugger behaves as if you started a new debug run. The nice thing about that is we are preserving initial state of the new timeline, won't have multiple paths to think through during replay, and maybe aligns better with the concepts in the debugger that are already implemented.

[Mytrill]

The runs feature actually comes from the hyperstart.io: there, all the previous runs are kept and can be explored (and soon, time travelled to...)

So I am not sure I am happy re-using this concept for time-travel.

Maybe we need a new concept/thing for this? You oppose to have the time travel as an action purely because of performance reasons (in which case, we could provide support for removing actions beyond a certain point) or because of concept reasons?

[mrozbarry]

Sorry, I'm not opposed to it, just hesitant.

Let me look at the how the data is going to look (in a broad sense):

• initialState
• input('t')
• input('te')
• input('tes')
• input('test')
• timetravel(1)
• input('ti')
• input('tim')
• input('time')
• timetravel(0)
• input('f')
• input('fo')
• input('foo')

That's not actually too bad. 👍

Maybe we want a special way to display timetravel so it's more obvious as a new app state. Not sure if that means just a little css and colour, or something else.

But okay, I can definitely get behind this. I guess a part of me still thinks through the lens of my debugger, which as a slider, which meant a huge amount of timetravels (no direct jumping to a state like in yours).

[Mytrill]

Hum, now that I see I am actually not sure I like it so much... :D

Maybe we can implement it this way for now since it should be very straight forward (maybe some extra css as you said) because it will still provide a lot of value, and then later we can review this feature...

What do you think?

[mrozbarry]

Yeah, we can definitely take an iterative approach. I'll get that sorted out tonight (UTC-5), and finish up the PR.

[mrozbarry]

Okay, this should be good to go :)

[Mytrill]

If I understand the PR properly, selecting an action automatically time-travels to it.

Should we make it a separate action? I find myself often inspecting previous states/actions to debug issues but I rarely time-travel to them.

What do you think?

EDIT: Actually I am ok with this (at least for now, may add a "time travel to" button, only visible when hovering over the action, or only visible on a selected action).

Thanks for the PR!