Undo & Redo Events

[00:00:00]
>> David Khourshid: I wanted to show you one more really, really cool thing and this is definitely, it was an extra credit item, but I don't expect you to build it out. So, normalization solution. And it goes to the original principle of events are the actual source of truth. And so let's say, like you see over here we have these two grayed out buttons.

[00:00:28]
Over here doing undo redo for text is easy because it is just a text area. You already have the browser's built in. Command or control Z command or control, Whatever the other one is, I'm blinking or control Y axis. It depends, there's different key mappings for redo. But the idea is that when you're working in an app where you have to make lots of changes, it actually is a pretty common request to say, hey, we do want to represent undos and redos.

[00:01:05]
And so by representing or by having events and events driven architecture, instead of just updating states, you actually sort of get that almost for free. So I wanted to demonstrate that just by showing you first the implementation and then how it looks. So in this reducer I actually have two extra events.

[00:01:29]
Over here I have undo and redo. And I also have a couple of extra fields in this date. I have the events, so we're keeping track of which events occurred. And also undos, which events were undone. So without changing too much of the actual data structure inside the reducer, when my action is undo, imagine that we have done a bunch of things here.

[00:01:59]
We entered the destination name, like Timbuktu, and added a few to do items over here. You could see that each one of these is an event. We created a destination, we created a to do, and then we created another to do. So what would undoing be? Undoing. Since we know that we're going to reach the exact same state if we replay all of those events, undoing is just replaying all of those events minus the last one.

[00:02:32]
Now, in reality, doing undos and redos is a little bit more complicated than that. But just for basic purposes, replaying all of the events up until the last one is more than sufficient. So if we go to solution over here, we can see that when we undo, we're replaying all those events and we have built in undo functionality.

[00:03:00]
So I'm going to undo again. And redos works similarly. So whenever we undo an event, that event goes into an undo array or a stack and then when we redo, we are just popping from that stack and then replaying just that event. So we already have the state for n minus 1 events.

[00:03:23]
So we just replay that event and that's essentially a redo. So we could basically redo and yeah, then we could rebuild everything just like that. And so that's why I really like events, because they contain all that extra data that allows us to do things like undo, redo, makes it easier to debug and things like that.

[00:03:51]
>> Speaker 2: Could we have a recursive reference to the previous state? And when we undo, do we have to check does state equal the previous state?
>> David Khourshid: Could we have a recursive and can do state equals. State equals state previous. So that's another thing about events. Events are tiny.

[00:04:16]
Imagine that you're building this to do list. You have 3, 4, 5, 6 to dos. And so you add them all up, it becomes a lot larger and you're having to keep track of these huge objects and there's a chance that you could run out of memory pretty fast if you do that.

[00:04:35]
And so events are smaller and you're going to get to a consistent state when you replay those events anyway. So, yeah, I would say that definitely is possible. And you could also, instead of keeping track of the entire previous date, you could keep track of state's diffs. But at that point, a state diff is essentially just a raw event.

[00:05:02]
It's telling you something happened. The state changed. We don't know why it changed. So it's just a very basic kind of event at that point anyway.