Component Architecture

Component Architecture

Modern web development follows component architecture. Angular is a front-end framework based on component architecture to develop scalable web applications. To understand the component architecture, let us consider the following example:

My home refrigerator has an LED screen on its door. It’s a smart fridge and is connected to Wi-Fi. The screen can be used for watching YouTube and other channels. In short, apart from refrigerating food items, which is a primary task of the fridge, I can use its screen as a TV. The fridge is kept in the kitchen for obvious reasons. Let us see the pros and cons of combining the refrigerator and TV in a single unit:

Pros

1. We do not need to buy a separate TV set and it is economical.

Cons

1. No Flexibility:

People usually watch TV in the living room, which is impossible now.

2. No Reusability:

As the TV is attached to the fridge, we can’t just move it freely. Even if we do, we’ll then have the fridge in another location different than the kitchen, where it’s needed.

3. Maintainability:

If something goes wrong with the refrigerating system, the LED screen (TV) may become useless too until the issue with the refrigerating system is resolved.

If similarly, some issue occurs with the TV and it stops working, we are left with two options:

a. To fix the issue with the TV, send the entire unit for repair, in which case although the fridge is working fine, we won’t be able to use it.
or
b. Keep using only the fridge without the TV.

4. Extensibility:

A TV (integrated) with the fridge will have limited functionality as manufacturer may not feel the need of implementing every new feature available for TV. Suppose a new hardware/software feature for TV sets is available in the market later, we may not be able to incorporate it.

From the above, we see that many inter-dependency issues are faced with this approach. TV and Refrigerator serve two different purposes. Hence considering the fridge and TV as two separate units would be beneficial. Each unit (TV or fridge) will encapsulate its functionality and respective dependencies. Each unit will then work as a self-contained independent entity or component.

We can define a component as “a self-contained unit enwrapping its own functionality and all its dependencies together.” The architecture that uses this approach is called component architecture.

Let us co-relate the above example with our front-end development/user interaction layer.

Suppose our website has two functional requirements:

a. Check the holidays when our consulting services are not available. (Calendar functionality)

b. Calculate the EMI for the user-entered loan amount and the duration of the loan. (Calculator functionality)

The above requirements can be incorporated into our website using either of the two approaches, namely: Traditional MVC and Component architecture. The next section compares the two approaches.

Approach 1: Traditional MVC approach

In this approach Model, View and Controller are separate layers. Accordingly, our application will be divided into:

1. A view/UI layer to enable the user:

· Select a date (to get information on holidays)

· Enter the amount and duration of the loan (to know the EMI)

2. A controller and a model layer to hold the logic/code for

· Finding holidays

· For calculating EMI

Placing the view and view-logic of the calendar in two separate layers hinders its reusability. The same applies to the EMI calculator. This approach does not permit us to reuse either a calendar or calculator in a ‘pick and drop’ style in some other places/applications. Besides, the approach makes calendar (or calculator) code difficult to modify or extend.

Approach 2: Component Architecture:

What if we combine the view and the view-logic together to form a single independent unit? In this way, the calendar’s view and view-logic will be merged to form a single independent unit, and the same will be the case for the calculator. Now the calendar and the calculator will be created as two different independent units, each encapsulating its own view and view-logic. These independent units are called components. In this way the calendar or calculator, each now being a separate self-contained entity, could be reused in a ‘pick and drop’ style. Any modification/extension for one won’t affect the other. Testability will also be improved for the same reason.

Let us define the component now.

A component is a self-contained unit:

· which owns its own presentation logic,

· view,

· internal state.

Example: Form-Button (an HTML form-entity that encapsulates its view and presentation-logic like click-ability etc. together). It is reusable and we can just pick and drop it wherever we need a button.

Thus, with component architecture, we can achieve reusability, flexibility, scalability, extensibility, and maintainability in web application development.

After understanding the component architecture and its benefits, let us dive into components in angular. The next section is dedicated to angular components:

Components in Angular:

Components are the main building blocks in Angular. An angular component is a TypeScript class annotated with the @Component decorator. Let us observe the two parts of the component file:

app.component.ts

1. class AppComponent: View-logic / view-Model

AppComponent is a TypeScript class. (Refer to line no.8 above). We declare variables and define methods inside the class. This is how the component gets its state and presentation-logic. For simplicity, we created just a single variable here as ‘title’ and assigned a value to it as ‘Hello World’. (Refer to line no.9 above). The value of the variable ‘title’ forms the state of the component.

2. @Component Decorator: View

Observe that the AppComponent class has been decorated with @Component. (Refer to line no.3 above). @Component decorator has various properties essential for creating the view of the component. Those are:

a. template/template URL

b. styleUrls

c. selector

Let us understand each one of them in detail.

2.a. template or templateUrl

Templates give a view to our component, or we can say templates declare how the component will render. The template combines ordinary HTML with angular syntax that allows angular to modify HTML before rendering it. The decorator @Component contains a metadata property as ‘templateUrl’. Here we specify the path of our template. (It is ‘./app.component.html’ in the above example). We can define this template either by file path or inline. In this example, we are using a file path. Let us look at the app.component.html file i.e., the template of our component:

App.component.html file / AppComponent Template

Observe that the template above has HTML markups and some angular syntax (double curly braces {{ }}). When we run our “Hello World” application, we get the following output in the browser:

View rendered in the browser.

We see that line no.1 of our component template is rendered as ‘My first component’ in subheading format as expected. Line no.2 of our template code ( {{title}} ) is rendered as “Hello World !!!”. Let us understand how it happens. Angular extends HTML by adding syntax elements so we can insert dynamic values from our component’s state.

Interpolation syntax

Refer to line no. 2 above. The state variable “title” is getting replaced by its value as ‘Hello World’. Through the syntax of double curly braces {{ — — }}, angular interpolates the contents within them. Hence “Hello World” the value of the state variable ‘title’ is seen in the browser. (Refer to the figure: ‘view rendered in the browser’ above.) Angular automatically updates the rendered DOM when the component’s state changes.

2.b. Styles /Style URLs

We can define CSS styles for components in two ways:

§ By using the ‘styles’ property of component metadata:

The styles property takes an array of strings containing CSS code. Refer to the figure below:

styles property with values

§ By using the ‘styleUrls’ property & providing a separate stylesheet:

We load styles from external CSS files by adding a styleUrls property and providing the path of the external CSS file as a value. (Refer to the figure below.)

styleUrls with path

Our external CSS file hello-world.component.css is as follows:

hello-world.component.css

2.c. selector

It is a CSS selector that defines how the component is used in a template. HTML elements in the template that match this selector become instances of the component.

To render our component, we use its selector value:

‘<app-root></app-root>’

in the template.

In the Hello World’ application, we are rendering AppComponent on the index.html page by using its selector as shown in the figure (line no.11) below:

Selector

Thus, we observed that the component view is specified through @Component decorator properties while view-logic and internal state are provided inside the component class.

In this post, we learned about the component architecture and an introduction to Angular components. Stay tuned!!!

Component Architecture was originally published in ngconf on Medium, where people are continuing the conversation by highlighting and responding to this story.

Leave a Comment

Your email address will not be published. Required fields are marked *