The ability to reply to discussions is limited to PRO members. Want to join in the discussion? Click here to subscribe now.

Structure a Complex Angular Component using Subcomponents

Structure a Complex Angular Component using Subcomponents

5:13
An Angular 2 cornerstone is component driven architecture and how we divide up our features into self-contained components and then fit them together. In this lesson, we will cover the basic structure of a component in an Angular 2 style as we build one from the ground up. Equally important, we will see how to integrate it into our application by adding it to our root component.
Watch this lesson now
Avatar
egghead.io

An Angular 2 cornerstone is component driven architecture and how we divide up our features into self-contained components and then fit them together. In this lesson, we will cover the basic structure of a component in an Angular 2 style as we build one from the ground up. Equally important, we will see how to integrate it into our application by adding it to our root component.

Avatar
Aurélien Noce

Would you see any downside in using an index.js file in the category module ?

It feels more natural to me to rename category.js to index.js so I can import categoryComponent from "./category" but maybe I'm forgetting something.

In reply to egghead.io
Avatar
Lukas

The only downside I can think of is that your code becomes less self-documenting from a high-level. For instance, I can quickly navigate to category.js from a hotkey and know precisely what it pertains to but if everything is named index.js, what module does it deal with? I then have to look at what folder it lives in to infer its functionality. I think index.js is a valid naming convention but for me personally, I prefer being explicit in my naming conventions.

In reply to Aurélien Noce
Avatar
Andrew

What is the benefit of creating components in separate modules? It seems like just using the 'app' module would remove a big chunk of the boilerplate code you had to write here.

Avatar
Lukas

A huge reason for this is isolation. By separating a component into its own module, I can test it in isolation without having to worry about instantiating every dependency in the application. This also promotes portability by allowing me to cleaning extract out a component and make it available for reuse in other projects.

In reply to Andrew
Avatar
Brian

at 1:40, you mentioned that we are using "./" to resolve the module from the current directory, instead of from the node_modules directory. Is resolving from node_modules the default behavior for imports? Where is this configured?

Avatar
Lukas

A Webpack expert can come in and correct me if I misspeak but that is a Webpack default. The presence of a . indicates a local dependency and without it, Webpack defaults to node_modules. This of course can be overridden in the config file but I have never had a need to do that.

In reply to Brian
HEY, QUICK QUESTION!
Joel's Head
Why are we asking?