Angular Introduction
Read one Angular interview question at a time, then flip for the complete explanation, example, and code.
0/90
Known
filtered set
Read one Angular interview question at a time, then flip for the complete explanation, example, and code.
Angular Interview Questions · Angular Introduction Companion Article
Angular is a web framework for building scalable web applications, maintained by a dedicated team at Google with an integrated collection of APIs, libraries, and development tools rather than a narrow focus on UI rendering. This companion guide explains how the major Angular concepts fit together, why Angular uses its current architecture, how modern Angular differs from older versions, and what to understand before moving into components, templates, signals, and other core Angular topics.
After completing this chapter, you should understand:
Angular is designed for building applications from reusable components. A component represents a portion of the user interface and combines application behavior with a template that Angular renders in the browser. Angular applications normally contain many components connected together as a component tree.
Angular is commonly used for applications such as:
Angular is not limited to one application size. A small application may have only a few components, while a large enterprise system may contain hundreds or thousands of components distributed across many business features.
A frontend application usually needs more than buttons and screens. Developers must also solve navigation, dependency management, forms, API communication, application state, rendering, testing, build configuration, deployment, and performance.
Angular provides official solutions for many of these concerns in one framework. Angular includes features for components, signals, Dependency Injection, routing, forms, server rendering, hydration, command-line tooling, and application development workflows.
This integrated approach is one reason Angular is commonly described as a framework rather than only a UI library.
A beginner can think of an Angular application using the following flow:
Browser
|
Angular Application
|
Root Component
|
Feature Components
|
Services
|
HttpClient / Business Logic
|
Backend APIThis diagram is intentionally simplified. Real applications may include routing, shared state, guards, interceptors, forms, server rendering, authentication, reusable libraries, and many other layers.
The key idea is that Angular applications are built from cooperating parts rather than one large JavaScript file.
Modern Angular architecture starts with components.
A component can contain other components, and those components can contain additional components. This creates a hierarchical component tree. Angular's documentation describes applications in terms of this component-based structure, with standalone components being the default in current Angular.
Consider an online shopping application:
AppComponent
|
|-- HeaderComponent
|
|-- ProductListComponent
| |
| |-- ProductCardComponent
|
|-- ShoppingCartComponent
|
|-- FooterComponentEach component has a focused responsibility.
HeaderComponent may display navigation.
ProductListComponent may display available products.
ProductCardComponent may display one product.
ShoppingCartComponent may display selected items.
Breaking an interface into components makes individual pieces easier to understand, test, reuse, and maintain.
An Angular component usually has a TypeScript class and a template.
The class contains data and behavior.
The template describes what should appear in the browser.
import { Component } from '@angular/core';
@Component({
selector: 'app-product',
template: `
<h2>{{ productName }}</h2>
<p>Price: {{ price }}</p>
`
})
export class ProductComponent {
productName = 'Laptop';
price = 65000;
}Angular connects the component class to its template.
When Angular evaluates:
{{ productName }}it reads the value from the component.
The separation between application behavior and presentation is one of the fundamental ideas behind Angular components.
Components rarely work completely independently.
For example:
ProductListComponent
|
| product information
v
ProductCardComponent
|
| user action
v
ProductListComponentA parent may provide information to a child, while a child may communicate an event back to its parent.
Modern Angular provides signal-based input() and output() APIs for component communication. Angular records inputs at compile time, and the output() API creates Angular outputs that components can emit to their consumers.
You will study these APIs in detail in later chapters, but understanding this data-flow relationship is useful from the beginning.
A component should not become responsible for everything.
Suppose a product page needs to obtain information from a backend server.
A poor design could place:
inside the same component.
A cleaner design separates responsibilities:
ProductComponent
|
v
ProductService
|
v
HttpClient
|
v
Backend APIThe component focuses mainly on the user interface.
The service handles reusable application or data-access logic.
This does not mean every function must be moved into a service. The goal is meaningful separation, not creating extra files without a reason.
Angular includes a Dependency Injection system.
Dependency Injection allows a class to receive the services it needs instead of manually constructing every dependency.
Imagine that OrderComponent requires:
OrderService
PaymentService
NotificationServiceWithout Dependency Injection, the component could become responsible for manually creating and configuring all three services.
With Angular DI, dependencies can be provided and resolved by Angular.
This separation improves areas such as:
Dependency Injection is therefore not simply convenient syntax. It is an architectural feature that helps large applications manage relationships between objects.
Older Angular applications commonly organized components through NgModule.
Modern Angular takes a different default approach.
Angular components are standalone by default. Angular documentation notes that before Angular 19, standalone defaulted to false; current components can directly import their template dependencies without requiring an NgModule declaration.
A simplified standalone component can look like:
import { Component } from '@angular/core';
@Component({
selector: 'app-welcome',
template: `<h1>Welcome to Angular</h1>`
})
export class WelcomeComponent {}This makes the component easier to use directly from other standalone components.
No.
Existing applications and libraries may still use NgModules. Understanding them remains useful when:
The practical rule is simple:
For new code, prefer current Angular patterns. For existing code, understand why the current architecture exists before rewriting it.
Angular provides a broad set of capabilities that work together as an application platform. Its current documentation highlights areas such as components, Signals, routing, server-side rendering, hydration, Dependency Injection, forms, CLI tooling, and development tools.
Components divide the user interface into reusable pieces.
Examples:
LoginComponent
DashboardComponent
UserProfileComponent
ProductCardComponent
OrderHistoryComponentTemplates describe the HTML Angular should render and allow Angular-specific expressions, binding, events, control flow, components, and directives.
Dependency Injection provides dependencies to components, services, and other Angular classes.
Angular Signals provide reactive state tracking. Angular tracks where signal state is used so it can update relevant consumers when that state changes.
Example:
import { signal } from '@angular/core';
count = signal(0);
increment() {
this.count.update(value => value + 1);
}The value stored inside count can participate in Angular's reactive rendering system.
Angular Router is the official Angular navigation library and is a core framework capability. It maps URLs to application views and supports navigation between features without requiring traditional full-page navigation for every route change.
Angular provides form APIs for handling user input, validation, and form state.
Angular applications can communicate with REST APIs and other HTTP services through Angular's HTTP facilities.
Angular supports server-side and hybrid rendering strategies. Server rendering can generate initial HTML before the Angular application becomes interactive in the browser.
Hydration allows a server-rendered Angular application to reuse the server-generated DOM when the client application starts rather than rebuilding everything unnecessarily. Angular hydration applies to server-rendered applications.
Angular CLI provides commands for scaffolding, developing, testing, deploying, and maintaining Angular applications.
Signals are an important part of modern Angular.
A signal stores a reactive value.
A computed signal can derive a value from other signals.
Effects can react to changes when integration with non-reactive APIs is needed.
Angular describes its signal system as granularly tracking where state is used so that rendering updates can be optimized.
For example:
import { computed, signal } from '@angular/core';
quantity = signal(2);
price = signal(500);
total = computed(() => this.quantity() * this.price());If quantity changes, total can automatically reflect the new result.
This is different from manually recalculating every dependent value.
Signals are useful for application state and reactive values.
RxJS remains useful when the problem naturally represents an asynchronous stream, such as:
User input events
HTTP workflows
WebSocket messages
Search requests
Combined asynchronous sources
Cancellation
Time-based operationsA mature Angular application may use both Signals and RxJS where each abstraction fits best.
Angular and AngularJS should not be treated as two names for the same framework version.
AngularJS refers to the Angular 1.x generation.
Angular refers to the modern framework that began with Angular 2 and continued through later versions.
The architecture changed substantially.
| Area | AngularJS | Modern Angular |
|---|---|---|
| Generation | Angular 1.x | Angular 2+ |
| Primary architecture | Controllers, scopes, directives | Components |
| Language commonly used | JavaScript | TypeScript |
| State/update model | Digest-era architecture | Modern Angular rendering/reactivity |
| Component model | Limited compared with modern Angular | Core architectural model |
| Modern Signals | No | Yes |
| Standalone components | No | Yes |
| Current development | Legacy | Active framework |
AngularJS official support has ended, so AngularJS should be treated as legacy technology when encountered in existing systems rather than a recommended choice for new development.
Suppose a company says:
Our application uses Angular.
Before making technical assumptions, confirm the version.
An AngularJS 1.x project and an Angular 22 project may differ dramatically in:
A developer moving from AngularJS to Angular 22 is performing a framework migration, not simply learning a few new syntax rules.
Angular and React both support component-based user interfaces, but they have different scopes.
Angular describes itself as a web framework, while the official React documentation describes React as a library for web and native user interfaces.
| Area | Angular | React |
|---|---|---|
| Primary description | Web framework | UI library |
| Component-based | Yes | Yes |
| Dependency Injection | Integrated Angular system | Not the same built-in framework model |
| Official routing | Angular Router | Usually handled through a framework/router choice |
| Forms | Angular provides form APIs | Usually selected according to React application stack |
| CLI/application tooling | Angular CLI | Depends on chosen React framework/toolchain |
| TypeScript | Strongly integrated | Supported |
| Reactive state model | Signals plus other Angular mechanisms | React state/hooks and ecosystem approaches |
| Application structure | More framework-defined | More dependent on selected React architecture |
The comparison should not become "Angular is better" or "React is better."
A practical technology decision should consider:
Angular can be attractive when a team wants an integrated framework and consistent conventions.
React can be attractive when a team wants React's UI model and prefers to select the surrounding architecture or use a React-based framework.
The correct choice depends on the application rather than popularity alone.
A Single Page Application, commonly called an SPA, changes the visible application view without requesting an entirely new HTML page for every client-side navigation.
Angular Router is designed to manage navigation in Angular applications and can interpret URL changes as instructions to display different views.
Consider these routes:
/products
/products/101
/cart
/orders
/profileThe user may move between these screens while the Angular application remains active.
A simplified flow is:
User clicks Products
|
v
Angular Router
|
v
Matches /products
|
v
Displays ProductComponentThis is different from a traditional website where navigation may request a completely new server-generated document for every page.
After the application has loaded the required resources, navigation can often update only the necessary portion of the interface.
For example:
Header stays visible
Sidebar stays visible
Only main content changesThe browser does not necessarily need to reload the entire document.
However, SPA architecture does not automatically guarantee good performance. Large JavaScript bundles, unnecessary dependencies, repeated network requests, expensive rendering, or poorly structured application state can still make an SPA slow.
A common Angular deployment issue appears like this:
Open homepage -> Works
Click /products -> Works
Refresh /products -> 404During normal client-side navigation, Angular Router may handle /products.
During refresh, the browser sends a direct request to the server:
GET /productsIf the server expects a physical resource at /products instead of returning the Angular application's entry document, it may return a 404.
This is why SPA deployment requires correct server configuration.
The exact solution depends on the environment:
Apache
Nginx
IIS
Node server
Cloud hosting
Static hosting
SSR architectureUnderstanding the difference between browser routing and server routing is more valuable than memorizing a single configuration snippet.
Modern Angular can use multiple rendering strategies.
An Angular application can use:
Client-side rendering
Server-side rendering
Static generation
Hybrid rendering
Hydration
Incremental hydrationAngular's current rendering documentation supports server and hybrid rendering, while hydration makes server-rendered HTML interactive on the client.
This matters because the old statement:
Angular is only a client-side SPA framework.
is no longer an accurate description of modern Angular.
Learning Angular means learning more than the @angular/core package.
The surrounding ecosystem provides tools for different application-development tasks.
Angular CLI uses the ng command and supports scaffolding, development, testing, building, deployment workflows, and maintenance.
Common commands include:
ng new
ng serve
ng generate
ng build
ng test
ng updateFor example:
ng new ecommerce-appcreates a new Angular workspace and application.
The Router manages application navigation.
Forms APIs handle user input, validation, and form state.
HttpClient is commonly used for communication with backend services.
Angular DevTools helps inspect and debug Angular applications.
The Language Service improves editor support for Angular templates and TypeScript development.
Angular Material provides ready-made UI components following Material Design concepts.
The Component Dev Kit provides lower-level behaviors that can be used to create custom component systems.
RxJS provides Observable-based asynchronous programming and remains relevant for stream-oriented Angular use cases.
The important lesson is not to memorize every package name. Understand which problem each part of the ecosystem solves.
Angular versions follow a three-part version format:
major.minor.patchExample:
22.1.2This can be read as:
22 -> Major
1 -> Minor
2 -> PatchAngular's official release documentation distinguishes major, minor, and patch releases and notes that Angular core and Angular CLI major versions have been aligned since Angular 7.
Example:
21 -> 22A major release may contain significant framework changes, migration requirements, API evolution, and compatibility changes.
Example:
22.0 -> 22.1Angular describes minor releases as containing smaller features while remaining backward compatible.
Example:
22.1.1 -> 22.1.2Patch releases are intended primarily for low-risk bug fixes.
An Angular application does not depend only on Angular itself.
Its development environment may also depend on compatible versions of:
Angular publishes an official compatibility table for actively supported framework versions. For Angular 22.0.x, the current table specifies compatible Node.js, TypeScript, and RxJS ranges rather than allowing arbitrary versions.
This is why upgrading Angular should not be treated as:
Change one number in package.json
Run npm install
DoneA professional upgrade includes compatibility review, migrations, testing, and production validation.
Angular provides ng update for framework updates and migrations. The official CLI documentation recommends the following basic update command for Angular core and CLI:
ng update @angular/cli @angular/coreA production upgrade should also include:
Check framework compatibility
|
v
Check third-party libraries
|
v
Run Angular update migrations
|
v
Review changed code
|
v
Run automated tests
|
v
Create production build
|
v
Test critical workflows
|
v
Deploy through controlled environmentsThis matters especially in large applications where a framework upgrade can affect many teams and dependencies.
Angular now works toward a major release approximately every 12 months, with around 4–6 minor releases per major and frequent patch or pre-release builds. Angular's documentation notes that before Angular v22 the project used a roughly six-month major-release cycle.
For Angular 22, the published schedule includes:
| Release | Approximate Schedule |
|---|---|
| Angular 22.0 | June 3, 2026 |
| Angular 22.1 | Week of July 27, 2026 |
| Angular 22.2 | Around September 2026 |
| Angular 22.3 | Around November 2026 |
| Angular 22.4 | Around January 2027 |
| Angular 22.5 | Around March 2027 |
| Angular 23.0 | Around June 2027 |
Angular notes that future release dates are guidance and may change.
Angular major releases are normally supported for approximately 24 months:
12 months Active Support
+
12 months Long-Term Support
=
Approximately 24 monthsDuring active support, regularly scheduled updates and patches are released.
During Long-Term Support, fixes are restricted mainly to critical issues and security problems.
For Angular 22, the official schedule currently shows:
Released: June 3, 2026
Active support ends: approximately June 2027
LTS ends: approximately June 2028This support model matters to companies because framework upgrades can be planned rather than postponed indefinitely.
Not every Angular API shown online has the same stability status.
You may encounter terms such as:
Stable
Developer Preview
Experimental
next
rc
DeprecatedThese labels matter.
A stable API is covered by Angular's normal compatibility expectations.
A Developer Preview API may be functional but is not yet covered by Angular's normal stabilization guarantees.
A next build represents a release under active development and testing.
An rc build is a release candidate undergoing final testing.
Angular's official versioning documentation defines next and rc as pre-release channels.
Therefore:
22.2.0-next.xshould not automatically be treated as equivalent to a stable Angular release.
A deprecated Angular API is not necessarily an API that immediately stops working.
Deprecation means Angular intends developers to move away from that API or feature.
Angular's current policy keeps deprecated functionality available for at least the next major release before it becomes eligible for removal, and removals occur as part of major releases.
When you encounter a deprecated API:
Do not panic
|
v
Read the deprecation documentation
|
v
Find the recommended replacement
|
v
Estimate migration impact
|
v
Add migration to technical roadmapThis is particularly important when maintaining long-lived enterprise applications.
Angular 22 was released on June 3, 2026 and is currently in its active-support period.
Angular describes v22 as a release focused on stabilization, template enhancements, API improvements, and modern application development.
Key Angular 22 areas include:
Signal Forms are listed as stable in Angular v22, moving signal-oriented form development onto a production-ready footing according to the Angular v22 release material.
Angular v22 also stabilizes its asynchronous signal capabilities, extending Angular's signal-oriented reactive model into more asynchronous application scenarios.
Angular Aria becomes stable in Angular v22, supporting the framework's accessibility-focused development direction.
Angular v22 introduces additional template ergonomics and improvements intended to make templates easier to develop and understand.
Angular reports improvements to core APIs involving performance, syntax, and typing in the v22 release.
Angular's current component configuration documentation states that OnPush is the default change-detection strategy starting with Angular v22. This reduces unnecessary checking by allowing Angular to focus updates on components when relevant notifications occur.
This is a particularly important version-specific point because many older Angular tutorials were written around the previous default behavior.
Older Angular applications often depended on ZoneJS to detect asynchronous browser activity and initiate application synchronization.
Modern Angular has moved toward zoneless operation.
Angular's current performance documentation states that zoneless change detection is the default for new applications from Angular 21 onward, so Angular 22 development should be understood in that modern context.
Zoneless does not mean Angular has stopped performing change detection.
It means Angular can rely on explicit framework-aware notifications, including reactive state changes and Angular events, rather than depending on ZoneJS to globally patch asynchronous browser behavior.
That distinction is important when reading older tutorials because some older recommendations assume ZoneJS behavior that is no longer the default architecture.
Imagine a shopping-cart counter.
The application needs to:
A simple modern Angular implementation can use a signal.
import { Component, signal } from '@angular/core';
@Component({
selector: 'app-cart-counter',
template: `
<h2>Cart Items: {{ itemCount() }}</h2>
<button (click)="addItem()">Add Item</button>
`
})
export class CartCounterComponent {
itemCount = signal(0);
addItem() {
this.itemCount.update(count => count + 1);
}
}The component stores the count in a signal.
The template reads:
itemCount()When the button is clicked:
addItem()updates the signal.
Because Angular tracks signal consumption, it knows that the template depends on itemCount and can update the relevant UI when the value changes. This reactive dependency tracking is a core purpose of Angular Signals.
This small example demonstrates several Angular concepts together:
Component
+
Template
+
Event Binding
+
Signal State
+
Reactive RenderingThat relationship is more important than memorizing each feature independently.
Consider a real product-management application:
User opens /products
|
v
Angular Router matches the URL
|
v
ProductListComponent loads
|
v
ProductService provides product logic
|
v
HttpClient obtains backend data
|
v
Component state changes
|
v
Angular updates the template
|
v
User sees productsIf the user clicks a product:
/products/101the Router can activate the product-details view.
If the product is added to a cart, shared cart state can be updated.
If the application uses SSR, the first page may be rendered on the server and then hydrated in the browser.
This is why Angular should be understood as a collection of connected architectural concepts rather than a list of unrelated features.
Angular has evolved significantly.
When reading tutorials, always check:
| Older Material May Emphasize | Modern Angular Direction |
|---|---|
| NgModules everywhere | Standalone-first architecture |
| Decorator-only patterns | Modern function-based APIs where available |
| ZoneJS assumptions | Zoneless-compatible architecture |
| Traditional template approaches | Modern built-in control flow and newer template APIs |
| Older reactive patterns only | Signals plus RxJS where appropriate |
| Client-only SPA thinking | CSR, SSR, SSG and hybrid rendering |
| Older change-detection assumptions | Modern v22 defaults and reactive notifications |
Standalone components have been the default since Angular 19, zoneless operation is the default from Angular 21 onward, and Angular's current documentation identifies OnPush as the default change-detection strategy from v22.
Older approaches are not automatically wrong. They may be completely appropriate when maintaining an existing application.
The key skill is recognizing whether code represents:
Current recommended architecture
Supported older architecture
Deprecated architecture
Legacy AngularJS architectureThey are not. AngularJS belongs to the old 1.x generation; modern Angular uses a substantially different architecture.
Angular can be used for applications of different sizes. Architecture and project requirements matter more than an arbitrary size label.
Not in modern Angular. Standalone components are the current default.
Modern Angular also supports server and hybrid rendering strategies.
Signals provide an important reactive-state model, but RxJS remains useful for asynchronous-stream problems.
Incorrect. Angular still updates views; the notification mechanism and change-detection architecture have evolved.
Incorrect. next and rc builds are pre-release channels and should be distinguished from stable releases.
Angular CLI also supports development, testing, building, deployment workflows, updating, and maintenance tasks.
Do not learn Angular as isolated syntax.
Instead of asking only:
What is a component?also ask:
Why should this UI become a separate component?
Who owns its state?
Which component supplies its data?
Should the logic belong in the component or service?
Does the feature need a route?
Can the feature be loaded separately?
What happens when its state changes?
Does it work during SSR?
How will I test it?
How will another developer maintain it?These questions turn Angular knowledge into application-development knowledge.
A strong learning order after Angular Introduction is:
Do not try to memorize the complete framework before creating applications. Build small features while learning each concept.
Before moving to the next Angular chapter, you should be able to explain these ideas without memorized definitions:
ng update is preferable to blindly changing dependency versionsIf you can explain these ideas with a small project example, you have enough conceptual foundation to continue into components, templates, binding, Signals, services, and other core Angular topics.