So, here is the frontend as is at the moment. We obviously need some form of edit button round about here. When I click that edit button, I want the content to appear in the same form above so that we take away some of the mental work from the user. The button should probably update to say, update comment, and obviously it should hit our new route that we created in the last episode. Let's get to work. We'll start in our Comment.vue file. We'll need to duplicate the delete button. We'll change the text to be edit, and you can see this if you have permission to update a comment. In order to add that, we'll need to go to our comment resource. Here in our can array, we have delete. Let's also add update, which will simply check the update method on our policy. Okay, with that added, when we click on this button, we want to send an edit event to the parent component, and we'll just need

will simply check the update method on our policy. Okay, with that added, when we click on this button, we want to send an edit event to the parent component, and we'll just need to add that edit event to define a myth down here. I think that's everything we need to change in the comment.vue file. Let's move on to the show page. Where we output our comment, we can now hook into that edit event, and let's create a method called editComment, which we'll add down here. Where do we want to place it? I think we'll place it above addComment because it's UI based rather than request based. So const editComment, and it receives the commentID, and then it can perform any action necessary. So we need to track some form of state that will allow us to say that a certain comment is being edited. We could have a piece of state called commentID being edited, which is equal by

to track some form of state that will allow us to say that a certain Comment is being edited. We could have a piece of state called commentIdBeingEdited, which is equal by default to a ref of null, but which will update inside here. So we'll say commentIdBeingEdited.value is equal to the given commentId from the event above. All right, why don't we have a computed property that will automatically go and fetch the correct comment from the list passed through props here. So we'll say const commentBeingEdited is equal to a computed property. And inside that computed property, we're going to search for and get a copilot might have got it right here. Let's check search for the comments data and find the first comment where the comments.id is equal to commentIdBeingEdited.value. That is perfect. So once we've set that in place, we should be able to say commentForm

first comment where the comments ID is equal to the comment ID being edited .value. That is perfect. So once we've set that in place, we should be able to say commentForm .body is equal to commentBeingEdited .value and we'll use an optional check just in case something goes wrong .body. So in other words, whatever commentID we've asked to edit, go ahead and grab that commentBeingEdited from the props past at the top here and then update the commentForm body to actually be the body of the edited comment. We should actually see this working in the browser. Let's take a look. So here's our first comment. I'll come to edit and I'll hit edit. And as you can see, right away, we have the text area populated with the text of this particular comment. If I click edit on the next comment, you can see the text changes. This is looking a little ugly and

we have the text area populated with the text of this particular comment. If I click edit on the next comment, you can see the text changes. This is looking a little ugly and isn't what I expected. Let's make a few adjustments before we carry on. First of all, maybe we'll get rid of text-right and use flex and we could say justify-end. And then let's use space-x-3 to add a bit of spacing between these buttons. And then we'll get rid of text-red-700 on edit because there's obviously no need to have a red button for edit functionality. See how that looks. Yeah, there we go. That's much better. So now we have a nice black edit button which we can click and the box fills up here. What else did we say? Well, when we actually fill this, when we move into edit mode, as it were, we should update this button here to say update comment rather than add comment. That's another easy task. We'll

we actually fill this, when we move into edit mode, as it were, we should update this button here to say updateComment rather than addComment. That's another easy task. We'll go back into our PostShow page. And up here where we have our primary button for submitting. Well, we can change addComment to a v-text. So v-text, which allows us to use a programmatic check. We can say, is there a commentId being edited? If there is, we'll use updateComment. Otherwise we'll use addComment as we've had previously. Let's see if that works. So in the browser again, you can see already it says updateComment. We should probably also have a way to cancel the update if you accidentally click edit and you don't actually want to update your comment here and now. So to achieve that, we could probably underneath add a secondary button, listen for the click and we'll have a method called cancelEdit.

want to update your comment here and now. So to achieve that, we could probably underneath add a secondary button, listen for the click and we'll have a method called cancelEditComment. And then perhaps we just have the word cancel inside the button there. Yeah, that works nicely. We only want to show this button if a comment is being edited. So we'll use a v-if to check if the commentId being edited is equal to null or not. There we go. So now it's disappeared. If I click edit, it should appear and it does. The last thing I'll do is add a class with maybe ml-2 just to provide a little spacing between the buttons. Let's go ahead and create a method called cancelEditComment. And perhaps we'll do that underneath editComment. This is what I really like about the composition API in Vue. You can group everything together really nicely and it makes it so much easier to come

that underneath editComment. This is what I really like about the composition API in view. You can group everything together really nicely and it makes it so much easier to come back down the line and update all of these things because they're in logical order rather than the order being forced upon you by the options API. So yeah, cancel editComment and we'll have our body here, which is going to say that the commentId being edited.value should be reset to null. And yeah, sure. Get help. Copilot's right. We'll also reset the commentForm at the same time. So let's see if this works. I'll click edit and yeah, sure enough, we have the text area updated. I click cancel and everything goes back to normal. I'll click edit on this one. I'll click cancel. Very cool. The last thing we need to do is wire this up to actually send a request to the backend to update the comment.

normal. I'll click edit on this one. I'll click cancel. Very cool. The last thing we need to do is wire this up to actually send a request to the backend to update the Comment. We'll handle the HTML for this first. So here is our form. Currently we just call addComment, but why don't we control this and again, conditionally call updateComment based on whether there is a commentId being edited. So if there is a commentId being edited, then we'll call updateComment. But if not, we'll carry on calling addComment and we'll have to now call these as methods instead of calling them in line as we have done before. Okay. Let's go ahead and create the updateComment method down here. And why don't we have this under addComment? I think that makes sense. So updateComment, it's going to be a method and we want to grab the commentForm as we did in addComment, but we'll make a PUT request.

add comment? I think that makes sense. So update comment, it's going to be a method and we want to grab the comment form as we did in add comment, but we'll make a PUT request this time because that's the correct HTTP verb for the route that we set up in the last episode. So we want to grab the comments.update route. We need to pass in the correct data. One will be the comment, which is going to be commentID being edited.value. But we also want to pass the page as we did here for deleting. So I'll grab that data and then let's go ahead and paste that in as well. Okay. Would that work just as it is? Let's see. We'll go back into the browser. I'll come down here and click edit on this comment. You can see the delete buttons have all just disappeared because an hour has passed now. But yeah, I'll come down, click edit. Let's go ahead and change this to ocean instead of sea. And we'll use

delete buttons have all just disappeared because an hour has passed now. But yeah, I'll come down, click edit. Let's go ahead and change this to ocean instead of sea. And we'll use a full stop, hit updateComment. We were taken to the top, which is hopeful. Yeah. As you can see now we have ocean rather than sea. We need to reset the form after the edit has completed. We've just created a pretty cool method to allow us to do that. cancelEditComment. So why don't we hook in here to the onSuccess handler, which we've discussed before and we'll simply call cancelEditComment. Let's see if that works. So we come to edit a comment here. I'll change it back to sea and then we'll update the comment, come down and the form has been reset. Perfect. We should also preserve scroll. So preserveScroll set to true and let's have that above to follow what we've done in all other circumstances.

and the form has been reset. Perfect. We should also preserve scroll. So preserveScroll set to true and let's have that above to follow what we've done in all other circumstances. Let's make sure that works. So we'll click edit. I'll update the comment without making any changes. And yeah, you can see there are zero issues there. We stay in line and we're able to see what we're doing. One thing I think will be the case if I come down to the bottom of a page and I click edit. Now technically the edit has worked. If I scroll up, you can see, yeah, this has filled out with the correct data, but that's not a very good user experience. There is no confirmation that we clicked edit. What we should actually do is move back up to the comment box here so that we can start making the edits straight away. At least for now, maybe in the future we'll have this float or be in some form of modal, but for now we

to the comment box here so that we can start making the edits straight away. At least for now, maybe in the future we'll have this float or be in some form of modal, but for now we should go back up the page to the comment form. In order to do that, I'll need a ref. So let's come back up here on the textarea. We'll create a ref for it. Let's call it the commentTextAreaRef. And we can grab that in the composition API simply by setting const commentTextAreaRef and then creating a ref that's null and viewable in the background link those two things together. So now when you click editComment, I want to set these, but then I'm going to go ahead and grab the commentTextAreaRef.value. And as long as it's filled, which should always be the case, but again, we'll use optional just in case I can call the focus method and the browser should do the rest. So let's try this out.

as it's filled, which should always be the case, but again, we'll use optional just in case I can call the focus method and the browser should do the rest. So let's try this out. I'll come to the bottom of the page here. I'll click edit and boom, we're taken straight back up the page. It fills out the body and we're ready to go ahead, make updates and click update comment like so. So brilliant. We have a working front end for updating a comment. Before we move on from front end work, I think we should spend a couple of episodes thinking about how we could improve the user experience here. As I've mentioned, it's too easy to delete a comment at the moment. We need some form of confirmation modal, and I think it would be a good idea to think about how we can create a reusable confirmation modal so that we can implement it anywhere across the site. And also there's no confirmation

I think it would be a good idea to think about how we can create a reusable confirmation modal so that we can implement it anywhere across the site. And also there's no confirmation when you actually click on something like addComment or updateComment. You know it's worked because you check the comments that appear underneath, but it would be nice if we had some form of toast system that allowed you to very easily see that you have successfully updated a comment. It's also a nice place for us to put any errors that might appear down the line. So let's tackle those two tasks in the following episodes.