Alright, next up, while we're still on the subject of Webpack, let me show you one more thing related to code splitting and optimization. So let's do this. I will compile, mix, and you'll see that we get our compiled app.js file that contains everything we need for the project to run. And of course, in development mode, it's always going to be very large. In this case, it's a tiny project and it's still a megabyte. But don't forget, for production, you would always compile in a production environment. So this will bring the file size down drastically, and then once you gzip it on your server, you should be good to go.

some other code splitting options. So let's do this. I'm going to go into my webpack.mix.js file, and the first thing I'll do is make a call to extract. So this will extract all node modules' dependencies into their own file. So have a look at this now. If I run it again, we're not just going to see a app.js file, we'll see two more here. And the most important one is this vendor.js file. And notice how big it is. And again, this is going to be any node module dependencies.

intact. And that can remain cached on the user's machine for a long time. Now if you take this approach, this is all outlined in the basic Mix documentation, but just make sure if you add vendor extraction, then in your app.blade.php file, you're no longer just importing the app.js file, you'll also need to pull in the manifest and the vendor JavaScript files. So do that here. manifest, then the vendor code, and then our app.js file. Okay, so if I open up Firefox and give this a refresh, everything's going to work just the way it did before.

Well right now, you'd still have to download all of the weight to make those function. So here's what we can do instead. Let's go into our resources/js/app.js file. And this is where we initialize our Inertia app. This is all fairly standard stuff that you'll get from the Inertia documentation. Notice where we create the Inertia app. Here's where we resolve the current page. And notice at the moment, we perform a common.js require. We check to see if we need to set a default layout, and then we return it. But now if I want to fetch these asynchronously, I'm going to swap this out with a call to

We check to see if we need to set a default layout, and then we return it. But now if I want to fetch these asynchronously, I'm going to swap this out with a call to import. But unfortunately, this isn't quite enough. import is now going to return not the page object, but a pending promise. And that promise will resolve once it has been loaded. Which means at the point I get right over here, yeah, I don't have a page object. I still have a pending promise. So we can use import.then, or I can use async await, like this. So now keep in mind, we have to get that default property off of the import.

So it's sort of a double-edged sword, right? For very large projects, this is incredibly useful. But you may find for smaller projects that just aren't that big, it's not worth it. You might even see a slight regression in performance, because you have to make this request and then process it. But you know what? Even saying that, it's still going to be incredibly fast. You'd probably never notice. All right, one last thing. On the Users page, we have this pagination component.

All right, one last thing. On the Users page, we have this pagination component. And we can find that in users/index, and yeah, it's right there. And just as it turns out for this demo, this is the only page that requires the paginator. So now because of our code splitting we have set up, here's my compiled files. If I look in app.js, I'm not going to see any reference to that pagination component. But I will find it as part of the page that requested it, in this case, that Users page. And there it is. And in this case, that's probably exactly what we want. Just to show you some options here, we could also conditionally load certain components.

And in this case, that's probably exactly what we want. Just to show you some options here, we could also conditionally load certain components and dependencies asynchronously. In view three, we do that through the defineAsyncComponent import. So now if I wanted to migrate this over, again, this is such a tiny thing, it just doesn't make a difference. But as a demonstration, I could say let or const pagination equals defineAsyncComponent and here we can return the import. Import, and what was it? SharedPagination.

paginator at the last possible minute when it's requested. Now, I don't think you'd ever do this for a basic pagination component, but you know what, for Laracasts, I do this quite a bit for things related to search. I use Algolia behind the scenes and some of those dependencies can get a little large, and it's a shame to make you download all of that code if you never even click on the search button. So that would be an example where this might be useful. But yeah, notice now, if I go back into our compiled assets, in the user/index file, we see the import here, but none of the actual logic is contained here anymore. Instead, all of it is within this single file.