There are two ways to register a component globally and locally. component method. This is what we call global registration and makes the components globally available in our application. Global registration often isn't ideal, however.
For example, if you're using a build system like VEET, Globally registering all components means that even if you stop using a component, it can still be included in your final bundle. This unnecessarily increases the amount of JavaScript your users have to download. Additionally, for some components, it just doesn't make sense to have them register globally. For instance, we will not use the plan component outside of the plan picker.
In cases like this, we can define the component as a JavaScript object. and then only register it where we need to use it. Let's do that. I'll create a variable called plan component and move the component options for that plan.
Finally, I'll remove the global registration of the plan component. Now, in the parent component, that is plan picker, we will use the components option to register the plan locally. The components option is an object. where the keys are the names of the components, and the value is the options object itself.
Now that our component is registered locally inside of PlanPicker, we cannot use it anymore outside of PlanPicker's template. Let's see what happens if we try to do that. In our template, I'll put a plan right here under the PlanPicker. Then, over in the browser, I want to give the page a refresh.
Sure enough, we don't see the super plan and if I take a look in the console we get an error saying failed to resolve component plan so yeah it's not available here I'll just remove it now we could do the same thing for the plan picker component since most likely we won't need to use it on every page of our website just like before let's create a variable to hold the options object in and then copy and paste that options object to it. And then lastly, remove the global registration. To register it locally now, we'll need to set PlanPickerComponent to the components option of its parent component. In this case, the parent is the root component instance.
If you prefer, you could use the hyphen syntax in the component's name by wrapping the key in quotes. This works fine too. However, If you leave it as Pascal case here, you can still use the hyphenated version when you use it over in your markup. Also, once you get to using single file components, you can even use the Pascal case in the markup as well, which is actually recommended by the official view docs.
To summarize, try to register only essential components globally, like a base button or an input, and register locally all the rest. However, if you are starting out prototyping. It's really not the end of the world if you register all your components globally and come back later to optimize your application. There are two ways to register a component globally and locally.
component method. This is what we call global registration and makes the components globally available in our application. Global registration often isn't ideal, however. For example, if you're using a build system like VEET, Globally registering all components means that even if you stop using a component, it can still be included in your final bundle.
This unnecessarily increases the amount of JavaScript your users have to download. Additionally, for some components, it just doesn't make sense to have them register globally. For instance, we will not use the plan component outside of the plan picker. In cases like this, we can define the component as a JavaScript object.
and then only register it where we need to use it. Let's do that. I'll create a variable called plan component and move the component options for that plan. Finally, I'll remove the global registration of the plan component.
Now, in the parent component, that is plan picker, we will use the components option to register the plan locally. The components option is an object. where the keys are the names of the components, and the value is the options object itself. Now that our component is registered locally inside of PlanPicker, we cannot use it anymore outside of PlanPicker's template.
Let's see what happens if we try to do that. In our template, I'll put a plan right here under the PlanPicker. Then, over in the browser, I want to give the page a refresh. Sure enough, we don't see the super plan and if I take a look in the console we get an error saying failed to resolve component plan so yeah it's not available here I'll just remove it now we could do the same thing for the plan picker component since most likely we won't need to use it on every page of our website just like before let's create a variable to hold the options object in and then copy and paste that options object to it.
And then lastly, remove the global registration. To register it locally now, we'll need to set PlanPickerComponent to the components option of its parent component. In this case, the parent is the root component instance. If you prefer, you could use the hyphen syntax in the component's name by wrapping the key in quotes.
This works fine too. However, If you leave it as Pascal case here, you can still use the hyphenated version when you use it over in your markup. Also, once you get to using single file components, you can even use the Pascal case in the markup as well, which is actually recommended by the official view docs. To summarize, try to register only essential components globally, like a base button or an input, and register locally all the rest.
However, if you are starting out prototyping. It's really not the end of the world if you register all your components globally and come back later to optimize your application.