So I think the next step will be to add a layer of filtering right up here. When the user types into a search box, we will dynamically update the results to include only the names that match that query. Okay, let's get started. I'm going to open up my User's component, and right up here at the top, we're going to add some kind of input here, and the placeholder will be search. Okay, let's see what that looks like. Give it a refresh, and yeah, but we want to get it right up here. So it sounds like we should wrap the H1 and the input within a div. I'll give it a reformat, and then on the div, I'll say, do a display of flex, and set it

So it sounds like we should wrap the H1 and the input within a div. I'll give it a reformat, and then on the div, I'll say, do a display: flex, and set it to justify-content: space-between, which means this will be pushed to the left, and this will be pushed to the right. Okay, now if I come back and refresh, it's a little better. But I do see a bit of margin here. So why don't we migrate that right up here. Okay, next, on the input itself, why don't we give it a class of border, and maybe a little padding on the left and right, and then finally, I will make the input rounded. Okay, let's see what that looks like.

little padding on the left and right, and then finally, I will make the input rounded. Okay, let's see what that looks like. Yeah, pretty good. So now, yeah, as I type into this, I want to update the results here, which means some kind of request to the server needs to take place. Okay, so it sounds like step one would be keep an eye on this input for changes. How do we do that? Let's set v-model, and I'll call it search. And then if we scroll down here, if I'm using script setup, all I have to do is define search and make it a ref, which I will import here, and we'll initialize it to an empty string.

And then if we scroll down here, if I'm using script setup, all I have to do is define search and make it a ref, which I will import here, and we'll initialize it to an empty string. And do note that we pulled that in. On the other hand, if you're using the options API, like you might be, then use that data method where you return an object like you normally do. So as an example, if I set foobar here, and I come back and refresh, the default value will now be foobar. Okay, so that's working. The next step, like I said, is to keep an eye on that input for changes. So let's pull in, we could do watch or watchEffect.

The next step, like I said, is to keep an eye on that input for changes. So let's pull in, we could do watch or watchEffect. Let's do watch. And now we'll say keep an eye on search for changes. And when that happens, at least to get us going, why don't we console.log changed, and then the value. And let's see how that looks. So we come back to Firefox, give it a refresh, open up Chrome. And notice as I type here, sure enough, I get the current value of the input. Great.

And notice as I type here, sure enough, I get the current value of the input. Great. Now, we will need to take care of situations like this where we perform too many updates if the user types quickly. But we'll deal with that in just a little bit. The important thing is we can now respond to when the user types into that search input. So let's perform a request. Now, up until this point, we've been using Inertia's link component, the wrapper around an anchor tag, to perform these requests. But we can also trigger it programmatically when you need to.

an anchor tag, to perform these requests. But we can also trigger it programmatically when you need to. And this is a good example of that. So again, if you're using the Options API, you know that you can do things like this.Inertia. But if you're using script.setup, you don't have access to this. So instead, we have to import it manually, like this. import Inertia from Inertia. Okay, so now I can say Inertia.get. Nice and clean.

Okay, so now I can say Inertia.get. Nice and clean. So let's make a GET request to the current page. And that would be /users. Now as the second argument, we can include any data that should go along with the request. So because this is a GET request, that would be included as part of the query string. So let's include search like this. Okay. So as you know, at the moment, on the back end, we're not doing anything to filter the result set.

So as you know, at the moment, on the back end, we're not doing anything to filter the result set. So that's not going to work. But if we did everything correctly, I do want to at least see an AJAX request take place. So I will type q. And sure enough, Inertia immediately makes a request to the server. And now it's including what we typed. But yeah, again, on the back end, we're not doing anything. We don't even know that exists. So we return the usual result set.

We don't even know that exists. So we return the usual result set. No change. Now before we fix that, though, notice that there's one weird thing here. If I type, it does make the request, but then it immediately resets the search input. And that makes sense if you think about it. When we run Inertia.get, that is equivalent to clicking on one of those link components, which means the whole page is going to re-render. And as part of that, it's going to clear out any state, like you see here, because usually that's what you want to happen when you visit a new page.

And as part of that, it's going to clear out any state, like you see here, because usually that's what you want to happen when you visit a new page. But in situations like this, it's a little bit different, right? I want to preserve the state. I don't want to lose what I type here. Okay, easy fix. All I have to do is, as the third argument, set the preserveState option to true. Now we're saying when we perform this request, don't get rid of the existing state on the page. All right, let's give it another shot.

But again, the important thing is, we are making a request to the server with the given filter. Okay, so now let's move over to Laravel. Let's go back to our routes file. And let's see, here's where we load that User's page. So it sounds like at some point here, we need to filter the incoming query based on whether or not we have search in the request. All right, let's get going. Now this could get a little messy, so a little tip here. You can begin a query by calling this query method.

Now this could get a little messy, so a little tip here. You can begin a query by calling this query method. And that just means start a new query. So often you'll see developers do this because it allows you to clean things up and put each method call on their own line, like this. Notice how that reads a little better. Next we're going to make this call to when. when is a cool method. It's basically a object-oriented conditional. We can say, if the given conditional turns out to be true, then append to the query in

It's basically a object-oriented conditional. We can say, if the given conditional turns out to be true, then append to the query in this fashion. Okay, so let's say look in the request for that search key. Now you can use the request helper function if you want, or we're kind of using facades here so I could say request()->input('search'); So if you found something there, only on that condition should you trigger this closure here. Or in other words, when you find something for the search input, append to the query in this way.

Or in other words, when you find something for the search input, append to the query in this way. So now it's very easy. Think about it. How would you filter down the users table? What query would you write? Well, you would do something like query()->where(), and we're effectively saying, give me only the records where the name matches what the user typed into that input. So I could say where('name', 'like', request()->input('search')), or that will be passed to me as the second argument.

So I could say where name, like, and I could retype request input search, or that will be passed to me as the second argument. So I can do it like this. So yeah, we could do this, but we really want to say anything can come before it, and anything can come after it. So as long as that search string exists somewhere in the name column, it's going to be a match. So we can do it like this, or why don't we use string interpolation, like that. Okay, let's see how that works. So I'm going to come back to Firefox, give it a refresh, and now you see it's working. We have a couple issues because maybe that search input should show what we previously.

But notice if I click on a new page here, hmm, I lost my search query here, and the input was reset. So let's figure out why. Let's go back, give it a refresh. We will search for something, but yeah, now if I have a look at any of these links, notice that they link to page two, but they ignore the current query string. Okay, well luckily, Laravel makes this a really easy fix. If I come back, after the paginate method here, I'm going to include this call to withQueryString. And this is nice because it reads pretty cleanly.

query string. And this is nice because it reads pretty cleanly. Paginate the results and include the query string as part of that. Okay, so with that one change, when Laravel generates the links down here, it's going to take into account the current query string. Notice if I give it a refresh and have a look at them now, they do include that search query, which means that should fix our current issue. Let's see, we're searching for us. The search input is still not reflecting what's in the query, so we'll fix that shortly. But if we did everything right, when I go to page two, it will be page two of the results.

The search input is still not reflecting what's in the query, so we'll fix that shortly. But if we did everything right, when I go to page two, it will be page two of the results with this current search. So that's looking good. All right, just a couple more things and then I'll let you go. What about the situation again when the User maybe lands on a page that already includes a search query? So if I get rid of this, what if they land on this page right here? Okay, well, it's showing search results for anything containing an S, but the input does not reflect that.

Okay, well, it's showing search results for anything containing an S, but the input does not reflect that. And that makes sense again. If I go back to my UserComponent, we initialized it to an empty string. So of course, that's the case. How do we fix this? Well, you have a couple of choices. One, on the client side, you could read the query string and say, well, if there is already something for search, then we'll set the initial value to that. Or you could pass it from the server side.

something for search, then we'll set the initial value to that. Or you could pass it from the server side. So let's do the server side approach. I will visit my routes file, and now we're going to pass through users, but also the existing filters on the page, like this. And that would be request, and you'd include any filters that you respond to. In this case, the only one is search. All right, so now when we load the page, the server is going to send to the client a list of approved filters, basically. Okay, now let's accept it from the view component.

of approved filters, basically. Okay, now let's accept it from the view component. Right up here, our props are now users as well as filters, which is an object. All right, let's have a look. Come back, give it a refresh. Open up view dev tools, and if we now look at the users page, there we go. Here's our two props. We have our users, and we have a list, again, of the approved filters that we want to work with. Okay, so now we only need to set the search's initial value equal to what we sent from the

with. Okay, so now we only need to set the search's initial value equal to what we sent from the server. So we'll say props.filters.search. All right, let's see if it works. Notice that we're currently searching for S, but it's not reflected in the input. But if I give it a refresh, now it is. Okay, so let's look for Enola. That works. It's in the query string.

That works. It's in the query string. And now if I give it a refresh, we remember it. Let's see if general pagination works. We have W. We go to the next page. The query string is updated. The input state remains unchanged, which we want, but the results update. Okay, so now we are just about done. The only remaining step is if I... Well, actually, real quick, let's open up a brand new window.