Alright, we're making good progress, let's get back to it. The first thing I'd like to do is go ahead and extract all of this to a dedicated function. So why don't we call it todos, or todoApp, maybe. And then right down here, we'll add a js todoApp.js file, and we can add that here. Okay, so now I can say todoApp, and then I will return this function like so. Actually, you know, let's just stick with todos. Alright, back to index, update this, and then reference our function. Okay, so with any luck, it should still work. Yeah, but now we have an extracted JavaScript file. Okay, next.

Yeah, but now we have an extracted JavaScript file. Okay, next. If I give this a refresh, let's start with something simple. I haven't created a single task, and yet it still says clear completed. That doesn't make any sense. Let's go to that now. And yeah, they even have a note for us. This should be hidden if there are no completed items. Okay, so only show this button if we have completed todos. So again, it sounds like we need a completed computed property.

Okay, so only show this button if we have completed todos. So again, it sounds like we need a completed computed property. Something like this. This would be a subset. Give me only the todos where the completed property has been set to true. Alright, let's see what we can do there. So we'll come on back. Sounds like we need another one here. Get completed. And this is very similar.

Get completed. And this is very similar. Filter down all of the todos and give me only the ones that are completed. Okay, so now if we jump back, if the length of completed todos is more than zero, then we show the button. Yeah, now I don't see it. Let's add a few and then complete at least one. And we do see it. Easy enough. Okay, what next?

Make it clear that we want to edit that specific todo. All right, let's come on back. Right here. Edit todo. We accept the todo in question. And yeah, again, I guess we have to decide, can you edit multiple todos at once? Or here's what I mean. Like, could we, we could do something like store it as state. So if we add editing directly on the todo, we could track that. That would probably be okay.

This is just a simple explanation with no code.

Yeah, I mean, we are storing if the task is completed. But it feels like edited is kind of a different thing. It's really not connected to the todo itself. Whereas completed very much is connected to it. So maybe it should be separate. Anyways, if we were to take that approach, what would we do here? Well, remember, we want to add a class. So we get the list side on a class of editing when we are in edit mode. So yeah, let's do this. Yeah, anyways, we're going to add a class of editing.

So yeah, let's do this. Yeah, anyways, we're going to add a class of editing. If, yeah, so we were talking about taking that approach. But instead, we're going to check if the current todo in the loop equals the edited todo that we just stored. I think that might do it. Let's give it a shot. Oh, nope. Nothing's working. Let's see.

Nothing's working. Let's see. Missing closing brace after property list. Oh, comma. Will that do it? Yeah. Okay, so now I double click. And there we go. But notice it still says rule the web. And that's because it's hardcoded.

But notice it still says rule the web. And that's because it's hardcoded. So down here, we won't use value. I will instead set $model to the body of the todo. Double click. And now I can change it. But what about confirming my change? We want that to be done when I hit the return key, right? So we're going to have a similar thing here. Where I say keyUp.enter should toggle us back to normal mode.

Okay. So how would we complete the edit? Well, first, editedTodo, which we are storing, it's really null. We want to bring that back to null. Because when we first edit, we basically cache which todo is currently being edited. Now that we're done, let's bring that back to null. We're not editing anything. And actually, right off the bat, the simple fact that editedTodo is no longer equal to the current todo. I think that'll just automatically work, won't it?

Of course you're following along. Let's see. Right here. Edited todo then becomes null. So this fails, which means we no longer add the class of editing. That's why that works. All right. So now I can type gibberish, double click to edit the todo, hit enter, and it works. And then I can complete it and then finally delete it. Okay, good for a first pass.

Yeah, this isn't what we want, is it? So, for example, we double click and if I make a change, well, if I hit enter, that confirms it, right? But if I make a change and hit escape, that means I want to revert back to whatever I had originally. So it sounds like we need to track what the original body of the task was. And then regardless of what you type here, if you hit escape, we revert back to that. Okay, so it sounds like when we begin editing a todo, let's come on back, we need to cache, we need to track what the current body is. So how about todo.cachedBody will be the current state.

we need to track what the current body is. So how about todo.cachedBody will be the current state. So before the user does anything, they double click, they're ready to change the task, but we first store what it originally was. That way, we could then say cancel, edit. And this would allow us to say, okay, I don't care what the current body is. I'm going to bring it back to what it originally was. And then I could say todo.cachedBody is null. Or really, at that point, I can just delete it, right? Any, yeah, anything else?

Or really, at that point, I can just delete it, right? Any, yeah, anything else? Oh, yeah, we should also do this. I guess I could just call that method. But let's just duplicate it. Okay, so now if you want to cancel and edit, we bring the body back to what it originally was. We're no longer storing the currently edited todo. And then we don't need the cache body anymore. So I'll just delete that.

It's only for a video tutorial. But if we can think of anything else to fix, we will. So for example, what if the user deletes everything or they only do spaces? If that's the case, we want to handle this correctly. So let's just see what happens. If I hit enter, nope. So let's make sure we handle that properly. It sounds like when we are finished editing, maybe we should do a little validation. For example, if the toDo body is an empty string, and in fact, why don't we just go ahead and trim any space off the edges?

Yeah, this section. Let's clean this up. All right. We're in business. So if I click on any of these, all I'm going to do is store which filter the user desires. So we might say something like, let's put this at the beginning. When you click on it, prevent the default action because we're not using a router here. And instead, I'm going to set the filter to... Do we want filter or filter by? Maybe just filter.

We'll do a little refactoring at the end. It sounds like I need a maybe up here. Filter. We'll default to all. So by default, we want to filter the to-dos according to everything. Everything gets through that filter. And actually, new to-do goes first. Okay. So now we're not doing anything with it. But if I click on one of these, we are updating that filter property.

Okay. Yeah, I'm not going to loop over all the to-dos. I'm going to loop over our filtered to-dos. So maybe you could add a method like getToDos, or you could add a computed property like filteredToDos. And that makes it a little more clear. Okay. Let's come on back. We have active, completed. Let's do another one.

We have active, completed. Let's do another one. Get filtered to-dos. And yeah, we're going to have to decide how we want to do this. Here's what I'm thinking. We could probably set up a simple lookup table. So we could say, well, like the long form without the lookup table. If the filter is all, then return all of the to-dos. And then you could say, well, if the filter is active, luckily we've already set up these computed properties.

And if I click on active, I should see the one that has not been completed. And then if I click on all, it shows me everything. All right. Like I said, though, I think it's easier to switch over to a lookup table. And this is a common pattern. You'll use it all over the place. So our lookup keys are all, active, and completed. And then we can just say all maps to our array of to-dos. Active maps to our active computed getter. And completed maps to our completed getter or accessor.

Active maps to our active computed getter. And completed maps to our completed getter or accessor. So now we have our lookup table. Let's just call the appropriate property. And then that will give us the value associated with that property. In this case, we want to grab the current filter that we are tracking. So now I can get rid of all of that. And it's a little bit cleaner, don't you think? Now, if you're confused about the array access, like if you come from the php world, that's just standard behavior.

So if we have active todos, which are the todos that have not yet been completed, and then we have completed todos, which are the todos that, of course, have been completed. If I want to clear the completed todos, that means the only todos that should remain are the active ones. So what if we updated the master todos array to be only the active ones like this? todos equals the active todos. It's so simple, and I think that will do the trick. One, two, three, four. Let's toggle one, two, three. And now if I clear completed, I should only be left with four.