What is @Component in Angular

There’s more to Angular components than what your To-Do app tutorial tells you.

By default, an Angular app generated by the CLI will have at least one component – the root component, often going by name app.component.ts

Under the traditional methods of learning Angular, tutorials would often skip over the finer details. They often recommend that you create a component for every view and partial view. However, as the project scales, you will find that this methodology is not very effective.

In part, this is because there’s no official or that much unofficial discussion around the idea of @Component, its functionality, when and where it’s appropriate to use them.

In this article, I will be covering everything you need to know about Angular’s @Component, including all the bits that beginner tutorials often exclude.

Side note: This is part 3 of a series. You can find Part 2 – How To Set Up Angular – here. Alternatively, you can also find all the posts so far in the series through the tag #AngularMasterySeries.

What is an Angular component

When it comes to the official documentation, a component is considered the basic building block of UI construction and is always associated with a template.

And that’s as far as it goes before diving straight into the technical parts.

So what exactly is an Angular component?

Think of a patchwork quilt. Each square, triangle, or whatever geometric shape used is a component of the overall blanket. All the different components add up to make a whole.

That’s what components essentially are in Angular.

Let’s take a look at the traditional To-Do app in its component form.

There are two views – or distinct pages – in the above example. These views are made up of unique and reusable parts.

The blue highlights where code can potentially be reused, making it a reusable component. This reuseable component sits inside a page – which is also a component itself.

A page component is not expected to be reused – unless it sits inside another component. Yes. You can have a component within a component (and so on, so forth).

At the very top of your nested view is your root component, which is shared by every view in the application. This space is often reserved for headers and footers, which can also be dynamic components themselves if state management is required.

When to use an Angular component

The point of components is that they act as the building blocks for your view and functionality.

Components can be abstracted out based on the behavior and requirements.

If you answer yes to one or more of the following questions, you should consider turning your code into a component.

  • is the view and functionality used in multiple places?
  • is the parent component getting too long? Splitting out a long parent component can help with code organization.
  • is a particular part of a page not updated as often as the rest of the code? Abstracting this kind of code out an act optimization and we call them optimization components.

What does an Angular component look like in code?

If you’re using the Angular CLI, you can use the following command to automatically generate the scaffold for a working component.

ng generate component your-component-name-here

Or use the alternative shorthand version:

ng g c your-component-name-here

This will give you code that looks something like this:

import { Component, OnInit } from '@angular/core';

   selector: 'app-test',  
   templateUrl: './test.component.html',  
   styleUrls: ['./test.component.css']

export class TestComponent implements OnInit {
  constructor() { }
  ngOnInit() {  }

There are three parts to the above code – the import, the @Component and the exported class.

The import portion pulls in the Component and OnInit modules from @angular/core. This lets you use the @Component decorator, which essentially tells Angular the meta-data required to make a component possible.

The selector tells us what the component is called and what will let it render inside other components. This means that if you want to display the above component, you just need to call it in a pair of tag form – <app-test></app-test>

The templateUrl lets the component know what view it is associated with. In theory, you can create an inline template. The Angular CLI just abstracts it out into a different file for code readability and references it using templateUrl.

The same treatment is applied to the component specific style sheet through styleUrls

The class that immediately follows exports itself as a module that is automatically declared in the app.module.ts file by the Angular CLI. Inside this class is where all your data and coding magic happens for displaying on the associated view.

When not to use an Angular component

It’s easy to abstract a UI into different and functional parts. However, one major space where components should not be made is when you need to manipulate the DOM.

When you abstract component code, you are looking at the data and not how the visual effects behave. That’s what attribute directives are for.

How can you tell the difference between DOM manipulation and things that change the DOM like ngFor and ngIf?

ngFor and ngIf are actually attribute directives that just happen to be built into Angular. They have the power to change the DOM layout by adding and removing DOM elements based on certain conditions and rules.

If you need to create a DOM manipulation yourself that’s not pre-built, then that should be abstracted into an attribute directive and used accordingly inside the component.

Not all decisions are equal

Abstraction can be a blessing for code quality – but also a curse when it comes to over-abstraction.

The first signs of over-abstraction are often signified by your code feeling messier than it should be after the abstraction.

The point of abstraction is to make your code easier to read, update and reuse. However, if after your abstraction, your code violates these things, then it means that you’ve made each part too little for their own functional good.

Sometimes, making a lot of tiny pieces for an application that hasn’t grown big enough yet can be unnecessary and overwhelming. In this case, keep your components how they were and don’t start breaking them down until there’s more data to process in code form on the page.

Thank you for reading

Thank you for reading and I hope you’ve found this piece useful. To help me out (and keep me motivated to write more), please like/share/comment.

This piece is part of a series and part 4 will be completed soon.



About Author /

I code. I write. I hustle. Living the #devLife remotely. Subscribe to my newsletter to stay connected with my latest posts and dev thoughts. Want to collaborate? DM me on LinkedIn

Leave a Comment

Your email address will not be published.

Start typing and press Enter to search