2. Angular Essentials - Components, Templates, Services & More

In this section, we will explore the essential Angular concepts every developer needs to master. We’ll do this by building a complete demo application from the ground up.

As we develop this demo app and implement its features, you will gain a clear understanding of the Angular project structure—how Angular projects are organized and the purpose of the various files and folders.

You will also dive deeper into the fundamental concept of working with components, which was introduced in the first course section. Additionally, we’ll cover other core topics such as TypeScript fundamentals and writing declarative code.

Specifically, you’ll learn how to handle user events like clicks and respond to them effectively. Moreover, you’ll discover how to write Angular code that enables dynamic rendering and updating of the user interface.

By the end of this section, you will be equipped to build dynamic, interactive web applications—just like the demo app we create together.

The content explains the setup and structure of a new Angular project created with the Angular CLI, recommending the use of a provided starter project to ensure a consistent starting point. It highlights that different CLI versions may create slightly different project structures, such as the location of the favicon file, but the Angular code remains the same.

Key points covered include:

Overall, the explanation provides a foundational understanding of the Angular project structure, configuration, and initial setup steps for development.

The content explains how Angular renders content on the screen starting from an almost empty index.html file containing a custom <app-root> element. This element is not standard HTML, so Angular takes over by executing code in main.ts, which is compiled from TypeScript to JavaScript by the Angular CLI. When the app runs (e.g., via ng serve), the CLI injects necessary script tags into the HTML automatically.

The key function executed is bootstrapApplication, which takes an Angular Component as an argument. This Component corresponds to the custom element tag in the HTML (app-root). The Component is defined as a TypeScript class decorated with @Component, a decorator that adds metadata to the class, turning it into an Angular Component.

The @Component decorator specifies a selector (app-root), a template URL (pointing to an external HTML file with the component’s markup), and styles scoped to the component. Angular replaces the <app-root> tag in the index.html with the component’s template content, rendering the title, subtitle, and image seen on the screen.

In summary, Angular compiles and injects scripts, bootstraps a root component linked to a custom HTML tag, and replaces that tag with the component’s template and styles, enabling dynamic content rendering in the browser.

The content explains how to build an Angular demo application by breaking the UI into multiple components, such as a header, sidebar, and dialog. Angular encourages creating these UI building blocks as individual components and composing them together. To start, the example focuses on creating a header component.

Key points include:

Overall, the approach emphasizes modular UI design in Angular by creating reusable components, starting with the header as the first step in building the demo app.

The text explains how to create a custom Angular component, specifically a header component, focusing on key configuration aspects:

The example includes creating the external HTML file with basic markup (a <header> element containing an <h1>), and notes that styles and further content can be added later. The explanation ends by posing the question of how to use the newly created header component.

The explanation covers how to properly use a custom Angular header component within an application:

In summary, Angular requires explicit component registration and encourages building a component tree with a single root component, importing child components where needed to render them properly.

The content explains how to style an Angular header component by creating a separate CSS file (header.component.css) and linking it via the styleUrl or styleUrls property in the component’s TypeScript file. Inline styles are possible but discouraged. It provides prepared CSS and assets (like a logo image) to be added to the project, including updating the global styles.css and index.html to import Google Fonts. The header.component.html is updated to include an image from the assets folder, with instructions to ensure the angular.json file properly references the assets path so images load correctly. Additional markup changes include wrapping the header text in a div and adding a descriptive paragraph. Once these changes are made and the development server is running, the styled header component will display correctly, marking the completion of the first custom component.

The content explains the process of creating and managing Angular components efficiently. Initially, it describes building a custom header component manually and highlights that as the number of components grows, organizing component files into feature-based subfolders (e.g., a "header" folder) inside the app folder is a common practice to maintain a clean structure. After moving files, import paths should be updated accordingly.

Next, it introduces the Angular CLI as a tool to streamline component creation. Instead of manually creating folders and files, developers can use commands like ng generate component (or the shorthand ng g c) followed by the component name (e.g., "user") to automatically generate the component files in a new folder. The CLI creates the standard files (HTML, TypeScript, CSS, and a test spec file) following naming conventions and sets up the component with a selector, external style links, standalone configuration, and an imports array for dependencies. The test file can be deleted if not needed immediately. This approach saves time and ensures consistency in component setup.

The user component was updated to include a div containing a button with a user image and a span for the user’s name. CSS styles were provided to improve its appearance. The user component’s TypeScript file required no changes. To use this component in the app component’s template, it was imported and added to the imports array, with Visual Studio Code offering a quick fix to automate this. The app component template was refined by wrapping the user component inside a main element and an unordered list with styling applied via updated CSS. The user component now displays but lacks the actual user image and name, which will be addressed next.

The current app uses placeholder images and names, which are not final and the image isn’t displaying yet. The goal is to support multiple users by using a provided dummy.users.ts file containing an array of user data (ID, name, image identifier). User images are supplied in a downloadable zip file, which should be extracted and placed into an assets/users folder, matching the image identifiers in the dummy data. The next step is to randomly select a user from this list and display their name and image dynamically in the user component. This requires learning Angular features to render dynamic content, moving beyond the previously static markup.

Goal: display a randomly chosen user’s data in an Angular component.

In user.component.ts

Because it’s a class property, Angular will expose selectedUser to the template.

In user.component.html

That’s all it takes to bind dynamic (random) user data from your TypeScript class into the component’s HTML.

Angular lets you bind dynamic data from your component class into your templates in (at least) two ways. The most straightforward is string interpolation: wrap any public (not private) component property in double curly braces, e.g.

Here, Angular’s tooling (for example in VS Code) will even auto-complete available properties and types. In our example, dummyUsers is an array of objects each with id, name, and avatar, so selectedUser.name inserts that user’s name into the view. Because the component picks a random user on each reload, you’ll see different names appearing whenever you refresh.

Angular provides two primary ways to insert dynamic data into your templates:

By combining these techniques, you can display text and configure element attributes dynamically—essential for building interactive Angular applications.

Instead of building complex strings or computations directly in your Angular templates, it’s better to move that logic into your component class via a getter. For example:

This keeps your template markup simpler and delegates all string‐construction or other computations to the class.

The content explains how to handle user input events in Angular by adding event listeners to elements in templates. Specifically, it shows how to listen for a button’s click event by using Angular’s syntax: placing the event name (e.g., "click") inside parentheses on the element, followed by an equal sign and a method call in quotes. The method, defined in the component class (commonly prefixed with "on" like onSelectUser), contains the code to execute when the event occurs. For example, logging "Clicked" to the console. When the button is clicked, the method runs, demonstrating how to respond to user interactions and update the UI accordingly.

The excerpt explains how to combine event handling and dynamic data binding in Angular to update the UI whenever a user is clicked. Instead of logging to the console, you store the clicked user in a component property (often called “state,” here selectedUser). To pick a different user on each click, you move the random‐index calculation into the click handler method so it runs every time. Assigning the newly selected user to the component property automatically updates the rendered template—no extra setup needed.

Angular automatically updates the UI whenever component data (state) changes. It does this by running its change-detection process, which compares the component’s template against the current data and applies any necessary DOM updates. Under the hood, Angular uses zone.js to hook into browser events (user interactions, timers, etc.). Whenever such an event fires, zone.js notifies Angular to run change detection, so you don’t have to manually tell the framework when to refresh the view.

Here’s a concise summary of the key points:

– Use the computed helper from @angular/core:

– Under the hood, computed returns a signal that re-evaluates only when its dependent signals change.
– You also read computed signals by calling them (imagePath()).

The instructor recaps that they’ve already gone through all the core Angular building blocks, but the demo app’s UI still only supports a single, randomly chosen user. The next goal is to turn the existing UserComponent into a truly reusable piece:

This approach leverages Angular’s component inputs to keep each user item simple, configurable, and reusable.

Here’s a concise summary of the steps and concepts covered:

Result: a reusable user component that takes avatar, name (and any other inputs) from its parent and renders a list of users dynamically.

The speaker is refactoring an Angular component to accept its avatar and name via @Input properties rather than hard-coding them. They initially used TypeScript’s non-null assertion (!) to convince the compiler those values would always be present—but that’s unsafe, since omitting one of these inputs at runtime (e.g. forgetting to pass name) would lead to a missing-data error. Angular’s @Input decorator can take a configuration object with a required: true option. By adding required: true, the framework and IDE will issue a compile-time/error if a caller fails to provide that input, aligning TypeScript’s guarantees with actual usage and catching mistakes earlier in development.

Angular lets you accept component inputs in two ways: the classic @Input decorator and the newer “signal”–based approach. Here’s a high-level overview of the signal approach and how it compares to the decorator approach:

Because of widespread legacy code and to cover both styles, the course will continue primarily with the decorator-based @Input approach, but you’ll now know how to do both.

Angular components don’t just consume data via @Input; they can also emit events back to their parent using @Output properties. In the example:

This child-to-parent communication is made possible by defining an @Output property (an EventEmitter) in the child component and binding to it in the parent.

Here’s a concise rundown of how to emit and handle a custom event in Angular:

And don’t forget to add any necessary type annotations so TypeScript stays happy.

Here’s a concise summary of the key points:

Here’s a concise summary of the exercise and solution:

Result: clicking a user updates selectedUserId, the getter finds the matching user, and TasksComponent displays that user’s name.