Nuxt lifecycle hooks act as checkpoints in the journey from the initial build of your application to the final rendering of the page. These hooks are like notifications from Nuxt, signaling you to execute specific code at many vital moments throughout this process. There are three main lifecycle hooks types in Nuxt 3. App hooks, and it has hooks during the application runtime.
Then we have Nuxt hooks, which are triggered during the application build time. And finally we have Nitro app hooks. And the hooks here are both server side and runtime. I gotta say, this is a very powerful hooking system to expand almost every aspect of Noxed.
But we can't use all of them in Noxed modules. And it actually makes a lot of sense because Noxed modules are triggered during build time and they are not accessible during runtime. So we can only use the hooks that are available during build time within the module entry point. We can still use other hooks inside the module as well, but inside the runtime directory, like inside a plugin for example.
But we will explain this in details later in the course. For now, just know, you can only use the build time hooks inside the module entry point. Now, let's have a closer look and take this ready hook here, which is triggered when Nuxt instance is ready to work. Inside the module entry point, we can start working with our hooks.
But first, I'll start by commenting out all the code related to the previous lessons, like so. Go down a little bit and start working with the hook. We can reach out for hooks using the Nuxt object, which is passed by the setup function right there. I'm going to use that to reach out for a method called hook.
And this method accepts the first parameter as a string for the name of the hook. And we see here VS Code autocompletion is lesting down all Nuxt hooks. but we will go with the ready hook. The second parameter is a callback function, so we can do that like this, and all your logic that you want to trigger when this hook is fired can be placed right here.
So let's console log any message. Noxt is ready and good to go. I'll hit save, open up the terminal, and start a dev server. And there it is.
Noxt is ready and good to go. This was logged to the console exactly when NoxedInstance was ready to be used. And some of these hooks are actually passing gifts too. Like for example, this NoxedReady hook over here is passing a NoxedInstance.
So let's log this NoxedInstance, like let's rename it to NoxedApp, to differentiate it from this Noxed over here. And let's log it to the console and have a look at it. Like so. Terminate the running server and then yarn dev.
Let's see what happens. And there you go, the whole Noxed instance is logged to the console. Cool! There is another way to use Hooks with the DefineNoxedModule object syntax.
We briefly mentioned it when we introduced the starter template, but we can use the Hooks property to listen to the application Hooks. And with this Hooks property, we don't have to use the Noxed instance to reach out for the Hook method, but we can directly write down the name as the key and the value will be a function. So if we copy the logic from here to here and pass the Nuxt app parameter like this, we will get the same outcome. There you go.
And this way you can use any of the hooks in one place with a clean straightforward syntax. Inside the build time Nuxt hooks list, let's find a couple of more hooks that we can use inside our module. I will go with the build before and the build done. the build before should be triggered before nox bundle builder starts and the build done is triggered after it's done or after it's completed so let's use those inside the module i'm going to use the build before like so passing a function and i'll console lock a message nox bundle builder starts and another one build done And console log a message.
Nuxt bundle builder. Finished. Let me take that off for better clarity in the console. Bring up the terminal and run a dev server.
And like we expect, it has the correct order. So the first thing that happens inside the application is that the Nuxt instance is ready to be used. And right after that... the builder starts and then it finishes and this is a good chance to mention that the ordering inside the hooks property doesn't matter like if we move this ready hook right below all the others it wouldn't make any difference we can run another diff server and we would have the same ordering there you go okay so i think we had enough with console logs i'll remove all of that and let's find something useful to do with the hooks Noxt has a hook called ViteExtendConfig and it allows us to extend Vite default config settings.
So why don't we use this instead of having to reach for Noxt options and then Vite in order to modify Vite config settings. So that will be fun. We need to change this approach to use a hook instead. Okay, let's see if we can do it here in the hooks property.
Name of the hook, an arrow function. And it's passing two parameters, the first one is ViteConfig and the second one is env, which holds information about whether the hook was triggered during the server side or the client side. Then we would need to grab this piece of code, right here, uncomment, and then replace NoxedOptionsVite with ViteConfig. Save, and now it's time to test.
Bring up the terminal, and let's build the application and preview it. Supposedly this will silence console logs, so if we have a console log right here, it shouldn't show up in the console. And it's not showing, no matter how many times I refresh, nothing is logged to the console from the message that we logged unmounted. Nice, so this works, but there is a problem.
What if we want this to be only activated when a user wants it to be activated, like we're doing here? and if condition if the user chose to opt for this option then just silence console logs and this is the trick while using the hooks property makes your code so elegant and organized but you will lose the direct access you have for the module merged options and the next instance passed by the setup function so whether to use the hooks property over here or the next hook method it depends on your specific use case so let me just remove this for now we don't need it anymore and uncomment all of that and let's grab this block of code right here for the hook and try to implement it down there so i'll comment this out and let's replicate it with the hook so it will go like this next hook i'll paste what we already have and change this to a comma then clear the old implementation from the if condition and replace it with our hook. And this will work the same way it did before. Now I'll use the Nitro config hook with these features over here.
So when this hook fires, it will then check if the module options has any of those options enabled and will proceed accordingly. Now that we got the hang of using hooks within modules, let's put it to a good use that aligns with our module's goal, which is optimization. Stay tuned for the next lesson.