Learn Livewire
This episode is for members only

Sign up to access "Learn Livewire" right now.

Get started
Already a member? Sign in to continue
Playing
15. Dynamic event names

Episodes

0%
Your progress
  • Total: 2h 52m
  • Played: 0m
  • Remaining: 2h 52m
Join or sign in to track your progress

Transcript

00:00
Now, I can't overstate how important it is that while you're building stuff with LiveWire
00:04
to keep your network tab open and watch really carefully for two things. First of all, the amount of requests that you're making to your back end with this update endpoint.
00:16
That's really important because you don't want too many requests. We've seen things like that with the live modifier where this will update for every character that we type.
00:25
And the second thing is the amount of data that you are rehydrating. Now, we spoke at the end of the last episode about how we're just focused on one book
00:34
and just updating one book. So all we need to do, or all we need LiveWire to do, is just rehydrate the book that we're focused on. So how do we do that?
00:44
Well, let's keep our network tab open. I'm going to give the page a refresh. And we're going to talk about specifically targeting elements that we need to with events, but by their ID.
00:55
So we've got this book editing method here, which we're actually going to get rid of because we're going to find out a better way to do this. But let's look at how we change this over.
01:04
So what's happening now is with this on event that we're using, this book editing event, this is actually being listened to because we are iterating through this book item.
01:15
It's being listened to by every single book item. There's nothing that distinguishes this event for individual books. So basically, when we, over in our update book,
01:26
call this method here or dispatch this event here, every single book is listening to that event. And then every single book on our page within our list of items is invoking this method.
01:38
And every single book is being updated. So we need a way to target the specific book that we're updating. Let's do that with this.
01:49
And then we're going to switch this over to a slightly different way of working. Okay, so we're going to start over here where we dispatch this event.
01:57
This is the most important part to start. What we want to do is we want to give this a unique ID. So what is the unique ID? Well, it's probably going to be the book ID.
02:06
So let's go down here and update this to say book, and then we'll add in here the book ID, this book ID. So we're now dispatching an event called book.one if it's the first book, and then editing.
02:22
So we're eventually going to change editing to being updated so we can just generally say that this book has been updated, and then as a side effect of it being updated,
02:29
we can toggle it. But that's basically the event name now. Now, this isn't going to work. So if we just head over and just edit one of these books,
02:37
let's edit this one, add another character on, hit save. Of course, it's not working. It's being updated in the database if we just give this page a refresh,
02:46
but the event isn't being listened to. So that is because we're listening to book.editing, not book.one.editing. So somehow we need to get this number
02:57
the same as the book that we're listening to in here, and therefore when we trigger the event, it will only listen to the book that we're updating. Now, to do this, we don't just go ahead
03:06
and concatenate on the book. In here instead, we use any of the properties in here that are models, and we just say book.id. So essentially now, this component will be listening
03:18
to only this book that we've passed in. Let's try this out, and more importantly, let's look at our network tab to see what's happening. So I'm going to pull this down slightly
03:28
just so we can see the other books, and again, I'm going to go ahead and add in just another character on the end of each of these. I'm going to hit save.
03:36
That toggled it. It refreshed the component, but let's take a look at this update now and see the difference.
03:42
So you can see that it has just gone ahead and given the HTML specifically for that book that we want to update. This is perfect.
03:51
It means that we're not updating and re-rendering the entire list of books when we don't need to because we're only editing one book at a time.
03:58
Now, let's just take a look at the kind of way we're doing this. Now, book editing is a completely valid toggle. There's nothing wrong with the code that we have written,
04:08
but it might be better to have a general updated event for a book, and then with that, we can do a list of things. We don't want to separate out these events too nichely. So we're going to go ahead and say book updated instead.
04:24
So we can call this method what we want to. Book has been updated. It doesn't really matter what we say, and we're going to get rid of this editing toggle
04:33
because what we can do is as a side effect of the book being updated, we can just set editing to false. We know that that's always what we want to happen.
04:41
We just want to get rid of the editing state. So we can go over to our update book and now change that to updated, get rid of this, and that's pretty much it.
04:50
So once a book has been updated, let our specific book component know or anywhere this is being listened to that this book has been updated,
04:59
and as a side effect of that book being updated, we just call a method to set editing to false, and we know that by calling this method, it will automatically re-render this component.
05:10
Anyway, it needs to re-render this component because it needs to get rid of that editing state. So hopefully that makes sense, but I think a more general event name for this
05:19
and a more general handler for this makes a little bit more sense. So let's go and just try this out. Again, just keeping our console open
05:28
just to double check this, and let's go ahead and edit another book down the page. So let's edit this one here and add an exclamation mark, hit save.
05:38
That gets updated. None of the others are re-rendered, and we can tell that by the markup that's being returned that hydrates,
05:45
and that is pretty much it. And of course, our toggle has been set to false because we are handling that within this general book updated handler.
05:55
So this is incredibly important stuff. It's so important to make sure that while you're developing, like I said at the start of the video, that we're not making too many requests to our backend,
06:05
but also that we're specifically targeting things that need to be re-rendered. So we're not re-rendering a huge list of items, in this case, books, when one gets updated.

Episode summary

In this episode, we dive into the essentials of optimizing your Livewire components, particularly focusing on how you handle events when editing items — in our case, books.

We kick things off by emphasizing just how vital it is to have your network tab open as you work, paying attention to how many requests your components are making, and how much data is sent back-and-forth. You learn why this really matters: You don't want your app making tons of unnecessary updates, especially when you're only editing a single item in a list — like just one book.

At first, we see that the way we set up our Livewire events causes every book item to listen to the same event. So, when we update one book, all the books re-render even though only one changed. Not good! To fix this, we update our event naming convention to include the book's unique ID, making the event names dynamic (like book.1.updated). This way, only the component relevant to the updated book listens and responds.

We go through the step-by-step changes needed in both the event dispatch and the listener, and see how this now causes only the right book to be updated in the DOM. Along the way, we talk about why making your event names general enough (like book.updated) makes your code easier to maintain, while still only targeting a specific book by passing its ID.

You’ll see first-hand (while watching your network tab) that now your app only updates the right component, and the rest of the list stays untouched — perfect for performance and for keeping the user experience snappy!

By the end, you’ll have a solid understanding of how to use dynamic event names to optimize when and how your components update in Livewire, making sure you don’t over-fetch or over-render your UI.

Episode discussion

No comments, yet. Be the first!