In this lesson, let's get hands-on and start creating our first Nuxt layer. Inside of the official Nuxt documentation, there is this great guide for authoring Nuxt layers. this is the really cool part. A layer structure is almost identical to a standard Nuxt application, which makes them easy to author and maintain.
ts file, even if that's just an empty config. but then they could also contain any other common directory that you typically have in a Nuxt application. Things like a components directory, composables directory, layouts directory, and so on. All of these work exactly as in an actual Nuxt application.
The only difference is that you could share what you have in that layer with multiple end applications. So how can we start creating our first layer? Well, Nuxt provides a handy template that is initialized through an npm command in order to get us started. Let's just copy that, and then over in our terminal, I'll paste it in.
Next, let's rename the layer to Nuxt Layer Project. This will be the name of the folder that it creates, and we'll run the command to see what that gives us. The first question is, which package manager would we like to use? I'm going to go with npm for now.
Initialize a Git repository. Sure, we can do that. Would we like to install any of the official modules? Since this will be a super simple layer for us to grasp the basics, the only thing I want to install here is eslint to catch any errors.
Perfect. Now let's open it up in our code editor and see what we're working with. In my code editor, I've started up the dev server with npm run dev. And in the browser, this is the result.
Notice that we're printing out a name that is my amazing Nuxt layer overwritten. How is this making it to the page based on what is in our file structure? Well, if you take a look at the file structure here, you'll notice that the root of the project is the code for our actual layer. config, as is this components directory.
This is all code that belongs to our layer. config for the layer, we're defining an app configuration object called my layer, and it has a name property of hello from Nuxt layer. If you come into the playground, this is that end user app that is extending the Nuxt layer. When I open up the Nuxt config here, notice that it includes an extends option that points to the parent directory.
ts, it has that same my layer configuration with the name property, but it defines it as something else. That's exactly why we are getting this on the page. view, here in the layer, we're printing out a hello world component. If I open up that component in the layer, it's grabbing the my layer configuration object from app config.
So because we're overriding the app config inside of our end user app, this is what actually makes it on the page. However, if we were to omit this from the end application, notice that we get the value from the layer. This is really, really cool. So this means we can extend layers, but then override portions of that layer that don't work for us in the end app.
If I were to create an app dot view file in my end application, and then copy what was inside of the app dot view for the layer, But add in our own little variation here. How about an h one that says hello from the end application? view that was in the layer. But very important to note here, we can still use the hello world component in the end application, even though the end application hasn't defined this component.
It's only defined inside of the layer. can't you just begin to see the possibilities here? Anything that you could write in a Nuxt application, now you can also write within a layer to make the same logic, functionality, composables, or components available across lots of projects. And you can do it in the exact same way as you do in the actual application.