Auto-Imports & Global Components

[00:00:00]
>> Now, we've done a lot of really interesting Vue 3 stuff, and honestly, some of these features we just did are pretty deep as far as the Vue 3 techniques go. And so, what I implore you to understand is that the reason I brought these into place, because they help to solve some pretty specific problems that we had.

[00:00:16]
It's really easy, especially as developers, to always wanna play with the shiniest and the edgiest technique. But remember that simpler and something that people can comprehend always trumps using the the most latest and greatest thing. And so, that's why I wanted to give you this solution where a lot of you are probably thinking like, well, if I had shared state, that might have been a little bit easier, and that is probably true.

[00:00:40]
But there are cases where when you have a base component, you really just want it to communicate. Because, imagine, a lot of us have base input, we have base form fields, you wanna be able to watch things. So, on a base form, you might have a first name field, a last name field, an email field.

[00:00:53]
Do you wanna manually tie that to some global store? It might make more sense to be like, here's my username form, and then for this particular page, I wanna watch the first name, the last name, the username. And you should be able to just do that without having to set up an entire store to share a state between, right?

[00:01:08]
And so, again, different types of modularity for different problems, different types, sizes of state sharing. So just something to consider as an option going forward. With all that said and done, though, don't worry, I did say the components are special in Nuxt, didn't I? And so, right now everything we've done is Vue 3, and so what exactly do I mean by that?

[00:01:28]
This entire time I've had you import components, and in fact most of you are probably used to importing components whenever you're trying to define components that you're going to use. So the most common of this, again, just for sake of definition, is actually let me not do this here.

[00:01:43]
And actually fun tip, you can actually have two script blocks inside of a single file component, one that's script set up, and one that's a normal script block. Because sometimes you need an actual component to export. Anyways, just know that it's possible. So this is actually not invalid syntax, but.

[00:02:03]
So, normally we register components. That's what we're used to, especially with Options API. And so what I showed you earlier, though, is that you don't need to register components. You don't need to register them manually inside of script setup because Vue knows that if you're importing this component, we know you're gonna use it.

[00:02:20]
So you don't have to define it a second time as something you have to actually register. Well, Nuxt takes that one step further and says, honestly, you know it's a component, you know where it probably lives. So, by default, you actually don't ever need to import any components on Nuxt at all.

[00:02:37]
To be clear, though, this does not mean that all of your components are bundled in every single page and every single build. This is a DX, developer experience, ergonomic thing, where they found that most people overall when using components could basically traceback, especially with things like go to definition.

[00:02:53]
So, for BaseDisplay, for example, if I go to right click > Go to Ddefinition, you'll see that theoretically, it'll actually tell me where it is if I really didn't know. And so, if that's the case, it was like, we know that our import statements at the top get really big anyway, so why be redundant with that?

[00:03:11]
And so that's one thing that's particularly special about that. Now again, it's a hotly debated topic cuz some people like being very explicit. And the reason I wanted to show you, cuz it's so important, is that, you're not forced to use their auto import functionality. The other special thing that you probably should know about when it comes to Nuxt components is they did apply convention where if you create a global folder.

[00:03:34]
And so let's say we drop BaseDisplay into global, this is something that will be built on everything now. Cuz it assume, you told it, it's a global component. And so, again, this is a very different paradigm from auto import. Auto import, an ergonomic thing, if you throw something in global, expect it appear to in the payload on everything that's loaded.

[00:03:54]
And so, this is not necessary a bad thing, the immediate instinct might be like, well, I should never do that. And we were talking a little bit about this at break, but anytime you hear in tech like a never or some sort of absolute, it's probably worth questioning.

[00:04:07]
Not to say that you shouldn't avoid it most of the time, but there are most likely exceptions and problems where the solution actually fits really, really well. And so, an example of this is if you have, let's say, a base button component. If you know 99% of your site uses this base button component, then it probably makes sense to just go ahead and have that loaded.

[00:04:28]
And then that way it doesn't have to be reloaded again, then the bundler can do performance optimizations. But otherwise, for most things, it's true, you probably will avoid this global folder, but just know that those are the two paradigms that Nuxt provides you when you're working with components.

[00:04:47]
Does anyone have any questions about the components stuff that we've gone over?
>> I'm assuming in Nuxt you should still import ref, computed, reactive, etc. Those are not implicitly-
>> So, I guess, since you're asking that, I will answer that question. So the stuff up here actually defineProps, ref, computed.

[00:05:07]
Let's just say the Nassim is very big fan of not having to import stuff that you probably will eventually just automatically know and use. And so, yes, some of these more popular composable, which I'll be explaining little bit later on, but the bottom line is a lot of stuff gets abstracted away at the end of it.

[00:05:24]
Should you choose to opt into it? The reason, especially when I teach like to define the import is so people can see where it comes from. And again, some people like that documentation in their code and there's actually nothing wrong with that, I actually see the benefits of that.

[00:05:37]
But for those who are really working quickly, want to see no more concise code, that's cool. Auto import is there for you. One more thing about components with naming. So, I know that it's very popular on project conventions to group components by folders. And, in my personal opinion, you should try to avoid that whenever humanly possible.

[00:05:57]
Because what happens a lot of times when you start letting developers use folders to organize their components is they kinda start getting a little bit lazy about the naming, and then it starts getting heavily nested. And when you have that happen across a team that's spread across the world, working in different time zones, solving tickets in silo, you will find yourself in a world of hurt.

[00:06:16]
When you have like 50 different button components, when 40 of them probably do roughly the same thing. And so, what I try to recommend actually is try to keep your component folder structure as flat as humanly possible. Don't get me wrong, there will come a point where you might be like, okay, it really does make sense to group all this stuff in a folder.

[00:06:35]
But the nice thing about having everything stay in one file structure is that whenever someone tries to create a duplicate component, they'll immediately get blocked, because you can't name the same file the same thing in the same folder. And more importantly, some people are like, well that makes scrolling really hard.

[00:06:49]
But that's what autocomplete's for, like Command+ P, find the component you want. So, there's also some other advantages, too, that I talk about in my production grade Vue course. But another thing that I also like to do is if you have unit tests for your components, I actually think it makes a lot of sense to put them right next inside of the component.

[00:07:06]
So if it is like jest.js, what this does is it actually makes it visually very obvious when your tests are missing from components. Whereas when they're split apart from a different directory, well, then it's always a kind of game of cat and mouse. But here, people could easily see, yeah, BaseDisplay has jest, nothing else has it.

[00:07:24]
There's something very nice about having information surface in an organic way. So that's a little tidbit to hopefully help you along the way. The one folder you'll probably see me have, especially in the Vue Eenterprise boilerplate, which will definitely be updated with Vue 3 soon, is that usually there is a base directory.

[00:07:41]
Because the base directory contains all your base components, and those are sometimes you do like, Chris Fritz, the President used to maintain it. He would have a script to auto import all the base components as a global component, because they were just used so frequently. And so, that's a good reason why you might wanna group something together, cuz you might be scripting something to wrap it all together and do something.

[00:08:01]
That's a great example of why that might work. So, that's a tidbit on that, and with that, that is the end of the components section.