Angular Questions

Angular is a TypeScript-based open-source web application framework led by Google. Unlike AngularJS (v1.x), which was based on controllers and $scope, Angular (v2+) is entirely component-based, uses a hierarchical dependency injection system, and provides better performance through AOT compilation and a more efficient change detection mechanism.

Angular's core features include its component-based architecture, two-way data binding, powerful CLI, dependency injection, and RxJS-based observables for handling asynchronous data. Additionally, it offers built-in tools for routing, forms management, and server-side rendering (Angular Universal), making it a comprehensive 'batteries-included' framework for enterprise applications.

TypeScript is a statically typed superset of JavaScript that compiles to plain JavaScript. Angular uses it because it provides better tooling, refactoring capabilities, and catches errors during development rather than at runtime. It also enables modern features like decorators, interfaces, and strong typing which are essential for managing large codebases.

A component is the fundamental building block of an Angular application. It consists of a TypeScript class that handles the logic, an HTML template for the UI, and CSS for styling. Every Angular app has at least one root component (AppComponent) that connects the component tree to the DOM.

An Angular component typically consists of four parts: the Component Class (logic), the Template (HTML structure), Metadata (defined via the @Component decorator), and Styles (CSS/SCSS). This structure enforces a separation of concerns while keeping the related logic and view tightly coupled for maintainability.

Decorators are functions that invoke metadata about a class, method, or property. They tell Angular how to process a specific piece of code. Examples include @Component for UI logic, @Injectable for services, @NgModule for modules, and @Input/@Output for component communication, essentially 'marking' the class for the Angular compiler.

The @Component decorator is a function that identifies a class as an Angular component. It provides metadata including the 'selector' (HTML tag name), 'templateUrl' (path to the HTML), 'styleUrls' (path to the CSS), and 'providers' (local services), allowing the compiler to transform the class into a functional UI unit.

A module (NgModule) is a container for a cohesive block of code dedicated to an application domain or workflow. It groups related components, directives, pipes, and services. While standalone components are now the default, modules remain crucial for organizing libraries and legacy application structures.

The @NgModule decorator defines metadata for a module. It includes the 'declarations' array (components/directives/pipes belonging to the module), 'imports' (external modules needed), 'exports' (elements visible to other modules), and 'bootstrap' (the main component to launch). It acts as the orchestrator for specific feature areas.

The root module, usually named AppModule, is the module that Angular bootstraps to launch the application. Every browser-based app must have a root module that imports BrowserModule. It provides the initial context for the compiler and defines which component should be loaded first in the index.html file.

The Angular CLI is a command-line interface tool used to initialize, develop, scaffold, and maintain Angular applications. You use it via the 'ng' command (e.g., 'ng new' to create a project, 'ng generate component' to scaffold code, and 'ng build' to compile for production), significantly improving development speed and consistency.

To create a new project, you ensure the CLI is installed ('npm install -g @angular/cli') and then run the command 'ng new project-name'. This command prompts you for configuration details like routing and stylesheet formats, then scaffolds the entire project structure including node_modules, source files, and configuration files.

Bootstrapping is the process of initializing the Angular application. It begins in the 'main.ts' file, where the compiler identifies the root module or root component. Angular then creates the root injector, renders the bootstrap component into the 'index.html' selector, and starts the change detection cycle via Zone.js.

Internally, Angular first loads the 'main.ts' entry point, which calls 'platformBrowserDynamic().bootstrapModule()'. This initializes the platform, parses the metadata of the root module, creates the component tree, and executes the first round of change detection to populate the DOM with data from the root component.

The 'main.ts' file is the main entry point of an Angular application. It is responsible for compiling the application with the JIT compiler (in dev) or pointing to AOT code and bootstrapping the root module or component to the browser environment. It essentially acts as the 'on' switch for the framework.

platformBrowserDynamic is a function that returns a platform factory for JIT (Just-In-Time) compilation in the browser. It allows Angular to compile the templates and components in the browser at runtime. For production, this is often replaced by AOT-related functions that load pre-compiled factory code for faster performance.

The 'index.html' is the single host page for the entire application. It contains the root component's selector (e.g., <app-root></app-root>). During build, the Angular CLI automatically injects the necessary JavaScript bundles into this file, which then manages the dynamic loading of all other views without refreshing the page.

app.component.ts is the TypeScript file for the root component of the application. It contains the logic for the top-most level of the UI. All other components created in the application are usually descendants of this root component, forming a tree-like hierarchy that originates here.

The lifecycle is a sequence of events that occurs from a component's creation to its destruction. Angular provides hooks like ngOnInit (initialization), ngOnChanges (property updates), ngAfterViewInit (view ready), and ngOnDestroy (cleanup). These allow developers to execute logic at precise moments in the component's existence.

Data binding is the communication between a component's TypeScript class and its HTML template. It allows data to flow into the template (interpolation/property binding), events to flow out of the template (event binding), or both (two-way binding), ensuring the view stays synchronized with the application state.

Angular follows the Model-View-ViewModel pattern. The Model represents the data/business logic; the View is the HTML template; and the ViewModel is the TypeScript class. The ViewModel handles the presentation logic and provides data to the View via data binding, acting as a bridge that abstracts the Model from the UI.

In MVC, the Controller handles the input and updates the View and Model. In MVVM (Angular), the ViewModel is a specialized controller that 'binds' directly to the view. Changes in the ViewModel properties are reflected in the view automatically via data binding, reducing the need for explicit DOM manipulation code.

An NgModule is a functional unit that organizes components, directives, and pipes into logical blocks. It helps in managing dependencies by defining what is available locally and what is exported for other modules. This modularity allows for features like lazy loading, where code is only loaded when the user navigates to a specific route.

Feature modules are NgModules used to partition an application into focused areas (e.g., UserModule, AdminModule). They isolate the code for specific business requirements, making the app easier to manage and allowing teams to work on different sections independently without causing conflicts in the root AppModule.

Shared modules are used to group frequently used components, directives, and pipes (e.g., a custom Button component or a Date pipe) into a single module. Other feature modules can then import this SharedModule to use those common assets, avoiding the need to declare the same component in multiple places.

Core modules were traditionally used to store singleton services that should only be instantiated once for the entire application (e.g., an AuthService). With the introduction of 'providedIn: root', core modules are less common, but they still serve as a place for global configuration and 'once-per-app' components like Navbars.

'Declarations' is for local components/directives/pipes. 'Imports' is for external modules your module needs. 'Exports' defines which declarations should be visible to other modules that import yours. This encapsulation ensures that internal helpers remain hidden while public APIs are exposed for reuse.

BrowserModule provides essential services for running Angular apps in a web browser. It includes built-in directives like *ngIf and *ngFor and handles the integration between Angular's change detection and the browser's DOM. It must be imported exactly once in the root module of every web application.

CommonModule contains the basic Angular directives like *ngIf, *ngFor, and pipes like DecimalPipe. While BrowserModule automatically includes CommonModule, you must import CommonModule directly in all feature modules (and standalone components) to use these fundamental tools in their templates.

Use FormsModule for 'Template-driven' forms, which are easier for simple use cases as logic stays in the HTML. Use ReactiveFormsModule for 'Model-driven' forms, which provide more control, better testing support, and handle complex validation logic more gracefully within the TypeScript class.

'Declarations' lists the components, directives, and pipes that belong to that specific module. 'Imports' brings in functionality from other modules. 'Exports' makes the local declarations visible to any other module that imports this one, essentially defining the module's public API.

Feature modules are NgModules used to organize an application into distinct logical sections (e.g., Auth, Dashboard, UserSettings). They isolate feature-specific components, services, and routes, making the application modular, easier to maintain, and allowing for efficient lazy loading of different application parts.

Standalone components simplify Angular by removing the need for NgModules. They reduce boilerplate, make components easier to reason about as they explicitly list their dependencies, enable better tree-shaking, and allow for easier component-based routing and lazy loading without creating extra module files.

Feature modules organize code by domain logic (e.g., UserModule). Shared modules contain reusable UI components, pipes, and directives (e.g., SharedComponentsModule). This separation ensures that the application is modular, maintainable, and allows for efficient code sharing and lazy loading across the project.

You create a component by running 'ng generate component component-name' (or 'ng g c component-name'). This command creates the TS, HTML, CSS, and spec (test) files, adds the component to the nearest module's declarations, and sets up the basic boilerplate code automatically.

Component metadata is the configuration data provided within the @Component decorator. It tells Angular where to find the HTML and CSS, what tag name (selector) to use to represent the component in HTML, and which providers or encapsulation strategies should be applied to that specific component.

A template is the HTML part of an Angular component. It defines how the component is rendered in the DOM. Templates use Angular-specific syntax like interpolation, property binding, and structural directives to transform static HTML into a dynamic representation of the component's state.

Inline templates are defined directly within the @Component decorator using the 'template' property (best for very short HTML). External templates are stored in a separate .html file and linked via the 'templateUrl' property, which is preferred for larger UIs to maintain better separation of concerns.

Template syntax refers to the special characters and directives used within Angular HTML to handle dynamic data. This includes double curly braces for interpolation {{ }}, square brackets for property binding [ ], parentheses for event binding ( ), and asterisks for structural directives like *ngIf.

Interpolation is a technique that allows you to embed dynamic string values into your HTML templates. Angular evaluates the expression inside the double curly braces (e.g., {{ title }}) and replaces it with the corresponding value from the component's TypeScript class, keeping the view updated automatically.

Property binding allows you to set the value of a DOM element's property or an @Input of another component. By using square brackets (e.g., [src]="imageUrl"), Angular passes the value of the variable from the TypeScript class to the view, enabling one-way data flow from logic to UI.

Event binding allows you to listen for and respond to user actions, such as clicks, keystrokes, or mouse movements. By using parentheses (e.g., (click)="onSave()"), Angular executes the specified method in the TypeScript class when the event occurs, enabling data flow from UI to logic.

Two-way binding combines property and event binding to synchronize data in both directions. Using the 'banana-in-a-box' syntax ([(ngModel)]="name"), changes made in the UI (like typing in an input) update the TypeScript variable, and changes in the TypeScript variable update the UI simultaneously.

Interpolation is used for embedding data as a string into the text of a tag or an attribute. Property binding is used to set element properties to non-string values (like booleans for the 'disabled' property). Property binding is generally preferred for setting attributes to avoid unnecessary string conversions.

Attribute binding is used to set the value of an attribute directly on an element when there is no corresponding DOM property (e.g., [attr.aria-label]="label"). This is essential for accessibility (ARIA) and for attributes like 'colspan' which are purely HTML-based and don't exist in the DOM property model.

Class binding allows you to add or remove CSS classes dynamically based on conditions. You use the syntax [class.className]="condition". If the condition evaluates to true, Angular adds the class to the element; otherwise, it removes it, providing an easy way to toggle styles based on state.

Style binding allows you to set inline styles dynamically using the syntax [style.propertyName]="value". You can also specify units, like [style.font-size.px]="fontSize". It is highly useful for applying specific, calculated styles to elements that change based on user interaction or data values.

Template reference variables allow you to use data from one part of a template in another part. By adding #name to an element, you create a reference to that DOM element or Angular component, allowing you to access its properties or methods elsewhere in the same HTML file.

@ViewChild is a decorator used to access a child component, directive, or a DOM element within the component's own view template. @ViewChildren is used when there are multiple instances to be queried, returning them as a QueryList that updates automatically when the view changes.

@ContentChild is a decorator used to access a child element or component that was 'projected' into the component via ng-content. Unlike ViewChild, which looks at the internal template, ContentChild looks at the content provided between the component's opening and closing tags in the parent template.

ViewChild queries elements that are part of the component's own HTML template. ContentChild queries elements that are passed in from a parent component (content projection). ViewChild becomes available in 'ngAfterViewInit', whereas ContentChild becomes available earlier in the lifecycle hook 'ngAfterContentInit'.

Content projection is a pattern that allows you to insert (project) HTML content from a parent component into a specific spot in a child component's template. Using the <ng-content></ng-content> tag, you create a 'placeholder' where the parent's provided content will be rendered at runtime.

Multi-slot projection allows you to project content into multiple specific locations within a component using selectors. By using the 'select' attribute (e.g., <ng-content select="header"></ng-content>), you can organize where different parts of the parent's content (like headers, bodies, and footers) should appear in the child layout.

ng-container is a special Angular element that can group elements together without adding an extra node to the DOM. It is primarily used to apply structural directives (like *ngIf or *ngFor) to a block of HTML when you don't want to add unnecessary wrapping <div> tags to your layout.

Content projection is the practice of passing HTML content from a parent component and displaying it in a specific location within a child component. It is achieved using the <ng-content> tag, allowing for the creation of highly flexible and reusable wrapper components like cards or modals.

ViewChild accesses elements within the component's own template. ContentChild accesses elements that were projected into the component from a parent via <ng-content>. ViewChild is initialized after 'ngAfterViewInit', while ContentChild is available earlier during 'ngAfterContentInit'.

@ViewChild accesses elements or components that are part of the component's own template. @ContentChild accesses elements that are 'projected' into the component via <ng-content> from a parent template. ViewChild is available in ngAfterViewInit, while ContentChild is available in ngAfterContentInit.

You use the 'select' attribute on the <ng-content> tag with a CSS selector (e.g., <ng-content select='[header]'></ng-content>). This allows the parent component to pass specific HTML blocks into specific named locations within the child component's layout for structured UI design.

Directives are classes that add new behavior or modify the appearance of elements in the DOM. They act as instructions to the Angular compiler. While components are technically directives with templates, standard directives are used to handle logic like showing/hiding elements, styling, or managing complex DOM interactions.

Angular supports three types of directives: 1. Component Directives (directives with a template), 2. Structural Directives (modify DOM layout by adding/removing elements, e.g., *ngIf), and 3. Attribute Directives (change the appearance or behavior of an existing element, e.g., ngClass or ngStyle).

Component directives are the most common type of directive. Every Angular component is essentially a directive with an associated HTML template. They define the UI and the logic for a specific section of the page and are identified by the @Component decorator which extends the @Directive decorator with view-related metadata.

Structural directives are responsible for HTML layout. They shape or reshape the DOM's structure, typically by adding, removing, or manipulating the elements to which they are attached. They are easily recognized by the asterisk (*) prefix, such as *ngIf, *ngFor, and *ngSwitch, which are shorthands for <ng-template> bindings.

Attribute directives are used to change the look or behavior of a DOM element, component, or another directive. Unlike structural directives, they do not add or remove elements; they simply 'sit' on an element like an HTML attribute. Common examples include ngClass, ngStyle, and the [(ngModel)] directive used for two-way binding.

The primary difference lies in their impact on the DOM. Structural directives change the DOM layout by adding or removing elements (marked with *). Attribute directives change only the appearance or behavior of an existing element without affecting the structural hierarchy. An element can have only one structural directive but multiple attribute directives.

*ngIf is a structural directive used to conditionally include or exclude an element from the DOM based on a boolean expression. If the expression is false, the element is completely removed from the DOM, not just hidden via CSS, which helps in improving performance by reducing the number of active DOM nodes.

*ngFor is a structural directive used to render a list of items by iterating over a collection. It clones the HTML element for each item in the array. It provides exported values like 'index', 'first', 'last', and 'even' that can be used within the template to customize the rendering of each list item.

By default, *ngFor uses object identity to track items. If the data source changes, Angular may re-render the entire list. 'trackBy' allows you to provide a unique identifier (like an ID). When the list updates, Angular only re-renders items whose ID has changed, significantly improving performance for large lists and preventing unnecessary DOM churn.

*ngSwitch is a set of three directives (ngSwitch, *ngSwitchCase, and *ngSwitchDefault) that allow you to conditionally swap entire chunks of UI based on a single expression. It works similarly to a JavaScript switch statement, where only the element matching the current value is rendered in the DOM.

ngClass is an attribute directive that allows you to add or remove multiple CSS classes simultaneously based on an object, array, or string. Using an object (e.g., {'active': isActive}), it provides a powerful and declarative way to manage complex styling logic that depends on the component's state.

ngStyle is an attribute directive that lets you set multiple inline styles dynamically. It accepts an object where keys are style names and values are the style values (e.g., {'font-size': isLarge ? '20px' : '14px'}). It is ideal for applying calculated styles that can't be easily pre-defined in a CSS class.

ngModel is an attribute directive used for two-way data binding in Angular forms. It belongs to the FormsModule. It synchronizes the value of an HTML form control (like an input) with a variable in the component class, ensuring that changes in the UI update the logic and vice versa instantly.

You create a custom directive using the @Directive decorator. For an attribute directive, you inject 'ElementRef' and 'Renderer2' to modify the host element. For a structural directive, you inject 'TemplateRef' (the content) and 'ViewContainerRef' (where it goes) and use them to add or remove the template dynamically.

To create a custom structural directive, you create a class with the @Directive decorator and a selector (usually in brackets). You inject 'TemplateRef' and 'ViewContainerRef' into the constructor. You then implement logic (often in a setter for an @Input) that calls 'createEmbeddedView' to show the template or 'clear' to remove it.

When the data in a list changes, Angular needs to know which elements to re-render. Without trackBy, it might replace the entire list in the DOM. trackBy provides a unique key, allowing Angular to only re-render the specific elements that actually changed, drastically reducing DOM manipulation overhead.

@HostBinding allows you to set properties (like classes or attributes) on the component's host element from within the TypeScript class. @HostListener allows you to listen to events (like click or hover) occurring on that host element, providing a way to handle events without adding listeners to the template.

You define a class with @Directive, inject 'TemplateRef' (to represent the content) and 'ViewContainerRef' (where to render it). You then implement a setter for an @Input that uses 'viewContainer.createEmbeddedView(template)' or 'viewContainer.clear()' based on the logic to show or hide content.

A component is technically a directive but has its own HTML template and CSS styles. A directive only adds behavior or styling to an existing element and does not have a view of its own. Use components for UI units and directives for reusable behaviors.

A 'trackBy' function helps Angular identify which items in a list have changed, been added, or removed. By providing a unique ID, Angular avoids re-rendering the entire list when only one item changes, which significantly improves performance for large data tables and lists.

Dependency Injection is a design pattern where a class requests dependencies from external sources rather than creating them internally. In Angular, the DI system provides instances of services to components and other services at runtime. It promotes loose coupling, makes code more modular, and facilitates easier unit testing by allowing mock injections.

DI is vital because it handles the lifecycle of objects and manages complex dependency graphs automatically. It allows for 'singleton' services shared across the app and facilitates 'hierarchical injection', where different parts of the app can have different instances of the same service, ensuring efficient resource management and cleaner code architecture.

An injector is the mechanism that maintains a container of service instances and creates new instances when requested. Angular has a 'Hierarchical Injector' system starting from the 'NullInjector', through the 'PlatformInjector' and 'RootInjector', down to 'ElementInjectors' at the component level, which determines the scope and visibility of services.

A provider tells an injector how to create or find a dependency. It maps a 'Token' (usually the service class name) to an implementation. Providers can be defined in the '@Injectable' decorator, in an 'NgModule', or directly in a component's metadata, defining the scope and availability of that dependency.

'providers' makes a service available to the component and all its children, including projected content. 'viewProviders' makes the service available only to the component's own view (its template children) and excludes any content projected into it via <ng-content>. This provides strict encapsulation for libraries and complex UI components.

The 'inject()' function, introduced in recent versions, allows you to inject dependencies outside of the constructor. This is particularly useful in functional contexts like 'Guard' functions, 'Resolvers', or when using 'Inheritance', as it avoids the need to pass dependencies through 'super()' calls, making code cleaner and more readable.

Services can be provided in four main ways: 1. In the @Injectable decorator using 'providedIn: root' (global singleton), 2. In an NgModule's 'providers' array (module scope), 3. In a Component's 'providers' array (component/children scope), and 4. In a Component's 'viewProviders' array (template-only scope).

'providedIn: root' is the modern and preferred way to provide services in Angular. It registers the service with the root injector, making it a global singleton. It also enables 'Tree-shaking', meaning if the service is not used by any component, it will be excluded from the final production bundle to save space.

Tree-shakable providers use the 'providedIn' syntax instead of listing services in an NgModule's 'providers' array. This creates a link from the service to the injector rather than the module to the service. Consequently, the build optimizer can safely remove the service code if no part of the application actually injects it.

When a component requests a dependency, Angular first looks at the 'ElementInjector' of that component. If not found, it moves up the parent component tree. If still not found, it searches the 'ModuleInjector' hierarchy (starting from the current module up to the root), finally hitting the 'PlatformInjector' before throwing an error.

An InjectionToken is used when you need to inject something that is not a class, such as a string, a configuration object, or an interface. Since interfaces are removed during compilation, they cannot be used as tokens; InjectionToken provides a unique, runtime-available hook for the DI system to identify these non-class dependencies.

Resolution modifiers are decorators used to change how Angular's DI system searches for a dependency. They tell the injector where to start looking or what to do if a dependency is missing. The four main modifiers are @Optional, @Self, @SkipSelf, and @Host, providing fine-grained control over the lookup process.

@Optional allows the dependency to be null if not found. @Self restricts the search to only the current element's injector. @SkipSelf forces the search to start from the parent's injector, ignoring the current element. These are essential for preventing circular dependencies and managing complex plugin architectures.

The @Optional decorator is used to mark a dependency as not strictly required. If the DI system cannot find the requested provider, instead of throwing a runtime error that crashes the application, it simply injects 'null' into the parameter, allowing the component to handle the missing dependency gracefully.

The @Self decorator tells Angular to only look for the dependency in the injector of the current component or directive. If the provider is not defined locally on that specific element, Angular will stop searching and throw an error (unless combined with @Optional), ensuring that global instances are not accidentally used.

The @SkipSelf decorator is the opposite of @Self. it instructs Angular to begin the search for a dependency in the parent component's injector, intentionally ignoring any provider defined on the current element. This is often used when a component wants to inject an instance of itself provided by a parent.

The @Host decorator tells Angular to search for the dependency in the current element's injector and continue up the hierarchy only until it reaches the 'host component' (the component containing the current template). It prevents the search from reaching beyond the component's boundary into the module or root injectors.

Hierarchical DI means that injectors are nested in a tree structure that mirrors the component tree. This allows you to have 'local' services that are unique to a specific branch of the UI. If a child component requests a service, it can get a different instance than its parent, enabling isolated state management.

'providedIn: root' creates a tree-shakable global singleton. Providing in an 'NgModule' also creates a singleton (if the module is only loaded once), but it is not tree-shakable. Use module-level providing only when a service must be restricted to a specific module or when using non-singleton lazy-loaded modules.

Multi-providers allow you to associate multiple implementation values with a single token. By setting 'multi: true' in a provider, you tell Angular that the token should return an array of all registered values rather than just the last one. This is heavily used for 'HTTP_INTERCEPTORS' and 'APP_INITIALIZER'.

Multi-providers allow you to register multiple implementations for a single DI token. By setting 'multi: true' in the provider definition, the injector returns an array of all provided values. This is essential for extensible systems like adding multiple HTTP interceptors or application initializers in a modular way.

The @Host decorator restricts the search for a dependency to the 'host component'. If the injector doesn't find the provider on the current element or its parents up to the host, the search stops. This is useful for directives that must interact with a specific parent component.

The 'inject()' function is a modern alternative to constructor-based dependency injection. It allows you to retrieve services in functional contexts like Guards, Resolvers, or when using inheritance, as it avoids the need for 'super()' calls and makes code more readable in functional programming styles.

'providedIn: root' makes a service a global singleton that is tree-shakable. This means if the service is not used anywhere in the application, the build tools will remove it from the final bundle, optimizing the application's size and memory footprint automatically.

A service is a broad category encompassing any value, function, or feature that an application needs. In Angular, it is typically a class used to organize and share code, such as data fetching logic, validation, or global state, between different components while keeping the components focused solely on UI presentation.

You create a service using the Angular CLI command 'ng generate service service-name'. This generates a TypeScript class file and a test file. The class is annotated with the @Injectable decorator, which enables the class to be used as a dependency in other components or services via the DI system.

The @Injectable decorator is used to mark a class as available to be injected as a dependency. It also allows the service itself to have other dependencies injected into its constructor. It essentially tells Angular's compiler to generate the necessary metadata for the DI system to manage the class instance.

@Injectable() simply marks the class as 'injectable' but doesn't register it anywhere; you must manually add it to a 'providers' array. @Injectable({ providedIn: 'root' }) both marks the class and automatically registers it as a tree-shakable, global singleton with the root injector, which is the modern standard.

The best way to share data between distant components is to use a shared service. The service can hold the state and expose it via 'RxJS Subjects' or 'Signals'. Components can then subscribe to these streams or use the signals to get real-time updates without needing to pass data through every intermediate component.

A singleton service is a service where only one instance exists for the entire application (or a specific module). Every component that injects this service will receive the exact same instance, allowing the service to act as a central hub for shared state and coordinated logic across the UI.

The most common way to create a singleton is to use the @Injectable decorator with the 'providedIn: root' property. Alternatively, you can provide the service only in the root 'AppModule'. This ensures that the root injector manages a single instance for the entire application's lifecycle.

The main purpose of services is to encapsulate reusable logic that doesn't belong in the UI layer. This includes tasks like making HTTP calls, handling authentication, logging, and complex calculations. By moving this logic into services, you keep your components lean, maintainable, and easier to test.

You inject a service by declaring it as a private or public parameter in the component's constructor, or by using the 'inject()' function. For example: 'constructor(private myService: MyService) {}'. Angular then automatically finds the provider for MyService and passes the instance to the component when it is created.

Injecting a service into another service works exactly like component injection. You define the required service as a parameter in the constructor of the receiving service. To make this work, both services must be decorated with @Injectable, allowing Angular to manage the chain of dependencies correctly.

Pipes are simple functions used in templates to transform input data into a desired output format for display. They are identified by the pipe symbol (|). Pipes do not change the underlying data; they only alter how it appears in the UI, such as formatting dates, currency, or uppercase strings.

Angular provides several built-in pipes for common transformations, including: 'DatePipe' (formatting dates), 'UpperCasePipe' (casing), 'LowerCasePipe', 'CurrencyPipe', 'DecimalPipe' (number formatting), 'PercentPipe', and the 'JsonPipe' (useful for debugging objects), which provide standard formatting out of the box.

A 'pure' pipe is only executed when its input arguments change. An 'impure' pipe is executed during every change detection cycle, regardless of whether the input changed. Pure pipes are highly performant but cannot track internal changes to objects or arrays unless the reference itself changes.

Pure pipes are significantly better for performance because Angular caches the output and only re-runs the logic when it detects a change in the input value. Impure pipes can cause performance bottlenecks as they execute frequently. Use pure pipes whenever possible, reserving impure pipes only for scenarios like complex filtering or tracking object mutations.

To create a custom pipe, you define a class with the @Pipe decorator and a 'name' property. The class must implement the 'PipeTransform' interface and its 'transform' method. The 'transform' method receives the value to be formatted and optional arguments, returning the final transformed value to the template.

The @Pipe decorator is a function that identifies a class as an Angular pipe and provides metadata about it. It requires a 'name' property, which is the string used in templates to apply the pipe (e.g., {{ data | myPipe }}), and an optional 'pure' property to define the change detection behavior.

The async pipe is a built-in tool that subscribes to an Observable or Promise and returns the latest value it has emitted. When a new value is emitted, the async pipe marks the component to be checked for changes automatically, significantly simplifying asynchronous data handling in templates.

The async pipe automatically unsubscribes from the Observable when the component is destroyed. This prevents memory leaks that occur when developers forget to manually unsubscribe in 'ngOnDestroy', making it the most efficient and safest way to consume data streams directly in the UI.

The DatePipe is a built-in pipe used to format date objects, numbers, or ISO strings into a human-readable format. It accepts various format strings (like 'short', 'fullDate', or custom patterns like 'dd/MM/yyyy') and handles internationalization based on the application's locale settings.

Parameterized pipes allow you to pass arguments to a pipe to customize its transformation logic. In a template, parameters are passed by adding a colon (:) after the pipe name, followed by the value (e.g., {{ amount | currency:'USD':true }}), allowing for highly flexible and reusable UI logic.

A pure pipe is only executed when its input reference changes (efficient). An impure pipe is executed on every change detection cycle (potentially slow). Pure pipes are used for data formatting, while impure pipes are used when you need to track changes within objects or arrays.

Angular provides two distinct approaches to handling user input: Template-driven forms and Reactive forms. Both are part of the @angular/forms package. Template-driven forms rely on directives in the template, while Reactive forms use an explicit, model-based approach in the TypeScript component class.

Template-driven forms use Angular directives like 'ngModel' to create and manage the underlying form model within the HTML template. They are asynchronous by nature and are best suited for simple forms with basic validation requirements, as they are easier to set up with less code.

Reactive forms (also called model-driven forms) provide a direct, low-level access to the form's object model. They are defined in the component class and use an immutable approach to state management. They are synchronous, highly scalable, and much easier to unit test than template-driven forms.

Template-driven forms are easy to use but harder to test and scale; the logic resides in the HTML. Reactive forms are more robust, provide better predictable data flow, and keep logic in TypeScript. Reactive forms also offer better support for complex, dynamic validation and nested form structures.

Reactive forms are generally preferred for enterprise applications due to their scalability, synchronous nature, and testability. Template-driven forms are excellent for very simple tasks or rapid prototyping. If your form requires dynamic fields or complex cross-field validation, Reactive forms are the definitive choice.

'FormControl' tracks the value and validation status of an individual field. 'FormGroup' groups multiple controls into a single object, managing their collective status. 'FormArray' manages an ordered list of controls, which is ideal for dynamic forms where users can add or remove fields at runtime.

FormBuilder is a helper service that provides syntactic sugar for creating 'FormGroup', 'FormControl', and 'FormArray' instances. It reduces the boilerplate code required to initialize complex form models, making the TypeScript class cleaner and more readable when defining large or nested forms.

Validation is performed by applying validator functions to form controls. Angular provides built-in validators like 'Validators.required' or 'Validators.minLength'. In templates, you can display error messages by checking the 'errors' property and the 'touched' or 'dirty' status of the control to ensure a good UX.

Built-in validators are a collection of static methods provided by the 'Validators' class. Common ones include 'required' (checks if empty), 'min'/'max' (numeric limits), 'minLength'/'maxLength' (string length), 'email' (basic format check), and 'pattern' (regex matching), covering most standard input validation needs.

A custom validator is a function that receives a 'AbstractControl' and returns either an object of validation errors (if invalid) or 'null' (if valid). You can then pass this function to the form control's constructor or the builders to implement domain-specific validation logic.

An async validator is a function that returns an Observable or a Promise that eventually emits a validation error or null. They are used for server-side checks, such as verifying if a username is already taken, and run only after all synchronous validators have passed.

The 'valueChanges' property is an Observable available on all form controls, groups, and arrays. It emits the current value whenever the user modifies an input or the value is changed programmatically, allowing developers to react to data changes in real-time for features like search-on-type.

The 'statusChanges' Observable emits the validation status ('VALID', 'INVALID', 'PENDING', or 'DISABLED') of a control whenever it is recalculated. It is useful for disabling a 'Submit' button or showing global form state indicators based on the current validity of the data.

In Template-driven forms, you use the '(ngSubmit)' event on the <form> tag. In Reactive forms, you can also use '(ngSubmit)' or simply trigger a method from a button click that accesses the 'form.value'. It is best practice to check 'form.valid' before processing the submission logic.

You reset a form by calling the '.reset()' method on the 'FormGroup' or 'FormControl' instance. This clears the values, resets the 'touched' and 'dirty' states, and sets the validation status back to pristine, effectively returning the form to its initial state.

FormsModule provides the necessary directives (like ngModel) and providers for creating Template-driven forms. It allows you to build forms where the logic is mostly defined within the HTML template using directives that synchronize the UI state with your TypeScript model automatically.

FormControl tracks the state (value, validity, touched) of a single individual input field. FormGroup tracks the state of a group of FormControls (or other groups), aggregating their values and validation status into one object, making it easier to manage whole forms as a single unit.

Routing is the mechanism that allows users to navigate between different views or components in a single-page application (SPA) without refreshing the entire page. It maps URL paths to specific components, enabling the creation of multi-view applications with browser history support.

The Angular Router is an official library (@angular/router) that enables navigation by interpreting browser URLs as instructions to change views. it manages the lifecycle of components during navigation, handles parameters, and provides hooks for security and data pre-fetching through guards and resolvers.

Routes are configured as an array of 'Route' objects, where each object typically contains a 'path' and a 'component'. This array is then passed to 'provideRouter' (standalone) or 'RouterModule.forRoot' to register the paths within the application's routing system.

'forRoot()' is used in the root module to initialize the router with the global configuration and service providers. 'forChild()' is used in feature modules to register additional routes without re-initializing the core router services, maintaining a single global router instance across the application.

The <router-outlet> is a directive that acts as a placeholder or 'slot' where the Angular Router renders the component associated with the current URL path. Every time the route changes, the component inside the outlet is swapped dynamically to reflect the new view.

The 'routerLink' directive is used on HTML anchor tags or buttons to navigate to a specific route. Unlike a standard 'href', it intercepts the click to prevent a full page reload, performing a client-side transition to the target path while updating the browser's URL.

The 'routerLinkActive' directive allows you to apply a specific CSS class to an element when its associated 'routerLink' becomes active. It is commonly used for navigation menus to highlight the current page, providing visual feedback to the user about their location.

Route parameters are dynamic segments of a URL (e.g., /user/:id) used to pass data to a component. They allow a single route template to handle many variations of a page, such as displaying different user profiles based on a unique ID passed in the path.

You access parameters by injecting the 'ActivatedRoute' service into your component. You can then subscribe to the 'params' or 'paramMap' observables to receive updates when the URL changes, or use the 'snapshot' property if you only need the value once during initialization.

ActivatedRoute is a service that provides access to information about the route associated with a component. It includes the URL, path parameters, query parameters, and data defined in the route configuration, serving as the bridge between the routing system and the component logic.

Query parameters are optional key-value pairs added to the end of a URL (e.g., /search?q=angular&page=1). Unlike route parameters, they are not part of the route path itself. They are used for optional data like filtering, sorting, or maintaining state across navigation.

Programmatic navigation is the act of triggering a route change through TypeScript code instead of a template link. You inject the 'Router' service and call 'router.navigate(['/path'])' or 'router.navigateByUrl()', which is useful for redirecting after a successful login or form submission.

The Router service is the core API for managing navigation programmatically. It provides methods to trigger navigation, inspect the current route tree, and listen to routing events (like 'NavigationStart' or 'NavigationEnd') to implement features like global loading spinners or analytics tracking.

Child routes allow you to define routes within other routes using the 'children' property in the configuration. This enables nested navigation where a parent component has its own <router-outlet> to display sub-views, which is essential for building complex layouts like dashboards with sub-menus.

Route guards are interfaces or functions that determine whether a navigation to or away from a route should be allowed. They provide security and logic at the routing level, allowing you to prevent unauthorized access, ensure data is saved before leaving, or pre-load necessary data.

Angular supports five types of guards: 1. 'CanActivate' (can the route be accessed?), 2. 'CanActivateChild' (can child routes be accessed?), 3. 'CanDeactivate' (can we leave the route?), 4. 'CanMatch' (can we even use this route?), and 5. 'Resolve' (fetch data before loading).

'CanActivate' is the most common guard used to protect routes from unauthorized users. It returns a boolean, an Observable, or a Promise. If it returns true, navigation continues; if false, navigation is blocked, and the user is typically redirected to a login page.

'CanDeactivate' is used to prevent a user from leaving a route if there are unsaved changes. It allows you to display a confirmation dialog. If the user confirms they want to leave, the guard returns true to proceed; otherwise, it returns false to keep them on the page.

'CanLoad' (now largely superseded by 'CanMatch') was used to prevent the application from even downloading the code for a lazy-loaded module if the user wasn't authorized. This saved bandwidth and added a layer of security by hiding the existence of certain code segments.

A Resolve guard (or Resolver) is used to pre-fetch data before a component is instantiated. The router waits for the resolver to finish before completing the navigation, ensuring that the component has all the necessary data ready as soon as it is rendered.

'CanActivate' runs after the module code has been downloaded and determines if the component can be shown. 'CanLoad' runs before the module is downloaded. 'CanLoad' is better for performance because it prevents unnecessary network traffic for modules the user isn't allowed to see.

You create a guard that injects an 'AuthService'. In the guard function, you check if the user is logged in. If authenticated, you return true; otherwise, you call 'router.navigate' to the login page and return false to cancel the original navigation attempt.

Lazy loading is a design pattern that delays the loading of NgModules or components until they are actually needed (i.e., when the user navigates to the route). This significantly reduces the initial bundle size, leading to faster initial load times and a better user experience.

You implement it by using the 'loadChildren' (for modules) or 'loadComponent' (for standalone) property in the route configuration, passing a function that returns a dynamic import. It is useful in large applications to split the code into smaller, manageable chunks.

In your routing array, you define a route where the 'loadChildren' property uses the import() syntax: '{ path: 'admin', loadChildren: () => import('./admin/admin.module').then(m => m.AdminModule) }'. Angular CLI then automatically creates a separate JavaScript bundle for that module during the build process.

The primary benefit is improved performance. By only loading the code required for the home page initially, the application starts much faster. Users only download additional code for feature areas (like 'Settings' or 'Profile') if and when they actually visit those specific sections.

A preloading strategy tells Angular to load lazy-loaded modules in the background after the initial application has started. This combines the benefit of a small initial bundle with the benefit of near-instant navigation when the user eventually clicks on a lazy-loaded route link.

Angular provides two built-in strategies: 1. 'NoPreloading' (default, no modules are preloaded) and 2. 'PreloadAllModules' (all lazy-loaded modules are downloaded as soon as the app is stable). You choose these when configuring the router in the root module or application config.

You create a class that implements the 'PreloadingStrategy' interface and its 'preload' method. You can then use custom logic (like checking a 'preload' flag in route data) to decide whether to load a module immediately or wait for certain conditions to be met.

Code splitting is the underlying build-time process where the Angular CLI (using Webpack or Esbuild) breaks the compiled JavaScript into multiple files. This is enabled by lazy loading and ensures that the browser doesn't have to download the entire application logic in a single, massive 'main.js' file.

Change detection is the internal mechanism by which Angular synchronizes the application's state with the UI. Whenever an event like a click, timer, or HTTP response occurs, Angular scans the component tree to check for property changes and updates the DOM nodes accordingly to ensure the view matches the data.

Angular performs change detection by traversing the component tree from top to bottom. It compares the current value of každého property bound in the template with its previous value (dirty checking). If a difference is found, the associated DOM element is updated. This process is efficient but can become a bottleneck in large applications if not optimized.

Zone.js is a execution context that persists across asynchronous tasks. Angular uses it to 'monkey-patch' asynchronous browser APIs like setTimeout, addEventListener, and Promise. This allows Angular to be notified whenever an async operation completes, so it can automatically trigger the change detection cycle to update the UI.

NgZone is an Angular service that wraps Zone.js. It provides a way to execute code inside or outside of 'Angular's Zone'. When code runs inside, it automatically triggers change detection. It also provides hooks like 'onUnstable' and 'onMicrotaskEmpty', which the framework uses to manage its internal rendering lifecycle.

You use 'ngZone.runOutsideAngular()' to execute code that should not trigger change detection, such as high-frequency events like mouse moves, scroll listeners, or animations. By running these tasks outside the zone, you prevent Angular from performing expensive tree-wide checks hundreds of times per second, significantly improving performance.

Angular offers two main strategies: 1. 'Default' (CheckAlways), where every component is checked on every event; and 2. 'OnPush' (CheckOnce), where the component is only checked if its @Input references change, an event originates from it, or you manually mark it for checking.

The OnPush strategy tells Angular that the component only depends on its inputs. Angular will skip change detection for this component and its entire subtree unless an @Input changes its reference, an observable bound with the async pipe emits, or the component manually requests a check via ChangeDetectorRef.

OnPush is crucial for scaling large apps because it prunes the change detection tree, reducing the number of checks from O(N) to only the paths where data actually changed. Effectively applying it requires using immutable data structures (to ensure input reference changes) and the async pipe for reactive data streams.

In a standard Zone-based app, any asynchronous event triggers change detection. This includes user interactions (click, submit), timer events (setTimeout, setInterval), and network events (XMLHttpRequest, Fetch). In 'Zoneless' mode (Angular 18+), it is triggered specifically by Signals, template events, or the async pipe.

You manually trigger it using the 'ChangeDetectorRef' service. You can call 'detectChanges()' to run change detection immediately for the current component and its children, or 'markForCheck()' to mark the component and its ancestors to be checked in the next global change detection cycle.

'markForCheck()' does not run change detection immediately but marks the component as 'dirty'. It ensures that even if the component uses the OnPush strategy, it will be included in the next change detection pass. This is typically used when data changes internally but not through an @Input property.

'detectChanges()' runs change detection for the component and its child components right now. This is useful when you have updated data and want the UI to reflect it immediately without waiting for an asynchronous event or the next global cycle, often used in unit tests or with third-party libraries.

Zone.js is a library that intercepts asynchronous browser events (like clicks or timeouts) to notify Angular that something has happened. This triggers the change detection cycle, allowing Angular to update the UI automatically without the developer having to manually tell the framework when data changes.

JIT compilation is the process of compiling the application in the browser at runtime. The browser downloads the Angular compiler along with the application code, analyzes the templates, and generates executable code on the fly. It is mainly used in development because it allows for faster reloads and easier debugging.

AOT compilation occurs during the build process on the server or developer machine. The compiler transforms HTML and TypeScript into efficient JavaScript code before the browser ever downloads it. This results in faster rendering, smaller download sizes (as the compiler is not shipped), and early detection of template errors.

The main benefits include: 1. Faster startup because the browser renders immediately; 2. Smaller bundles as the compiler (~1MB) is excluded; 3. Better security because templates are not evaluated via 'eval()'; and 4. Early error detection where binding errors are caught at build time rather than at runtime.

In production, the compiler runs Ahead-of-Time (AOT). It converts HTML templates and TypeScript code into efficient JavaScript instructions before the user downloads the app. This eliminates the need for the compiler at runtime, reduces bundle size, and ensures faster initial page rendering.

RxJS (Reactive Extensions for JavaScript) is a library for composing asynchronous and event-based programs by using observable sequences. It provides a core type, the Observable, and operators that allow you to treat events and data streams like arrays—filtering, mapping, and combining them with ease.

An Observable represents a stream of values that can arrive over time. Unlike a Promise, which resolves to a single value once, an Observable can emit zero, one, or many values and stays open until it is either completed or errored out. They are 'lazy', meaning they don't execute until subscribed to.

A Promise is eager, non-cancellable, and handles a single event. An Observable is lazy (starts on subscription), cancellable (via unsubscribe), and can handle multiple values over time. Additionally, Observables provide a rich set of operators for complex data transformations that Promises lack.

A Subject is a special type of Observable that allows values to be multicasted to many Observers. While plain Observables are unicast (each subscriber gets their own execution), a Subject acts like an event emitter; it maintains a registry of many listeners and 'broadcasts' the same value to all of them simultaneously.

A BehaviorSubject is a type of Subject that requires an initial value and always emits the 'current' value to new subscribers. It is commonly used for representing application state, ensuring that any component that subscribes late still receives the most up-to-date data immediately upon subscription.

'switchMap' is a transformation operator that maps each source value to an inner Observable. The key feature is that it cancels the previous inner Observable when a new source value arrives. This is ideal for search features where you only care about the result of the latest request.

'mergeMap' (also known as flatMap) maps each source value to an inner Observable and merges all inner Observables into one. Unlike switchMap, it does not cancel old requests; all emissions from all inner Observables are processed concurrently, which is useful when all results are important regardless of order.

'concatMap' maps values to inner Observables but processes them sequentially. It waits for the current inner Observable to complete before starting the next one. This is essential when the order of operations matters, such as ensuring that database updates are processed in the exact order they were triggered.

'exhaustMap' maps to an inner Observable but ignores all new source values until the current inner Observable completes. This is the 'ignore until done' operator, perfect for preventing double-submissions on a login or save button while the first request is still in flight.

'combineLatest' waits for all streams to emit once, then emits whenever *any* stream changes. 'withLatestFrom' emits only when the *primary* stream emits, using the latest values from others. 'forkJoin' waits for *all* streams to complete and emits only the final values (similar to Promise.all).

'map' is a standard transformation operator that modifies each emitted value (1 to 1). 'switchMap' is a flattening operator that maps a value to a *new* Observable and switches to it, cancelling any previous active inner Observable. Use 'map' for data changes and 'switchMap' for dependent async calls.

A ReplaySubject caches a specified number of previously emitted values and 'replays' them to any new subscriber. Unlike BehaviorSubject, which only stores the *last* value, ReplaySubject can store a whole buffer of events, making it useful for logging or synchronization of historical state transitions.

'takeUntil' is a filtering operator that emits values from the source Observable until a second 'notifier' Observable emits a value. It is the most common pattern for manually managing subscriptions in Angular components to prevent memory leaks, usually by triggering the notifier in 'ngOnDestroy'.

You can unsubscribe manually by calling '.unsubscribe()' on the Subscription object returned by '.subscribe()'. Better practices include using the 'async pipe' in templates (automatic cleanup), the 'take(1)' operator for one-time emissions, or the 'takeUntil' pattern with a subject that emits during component destruction.

The 'debounceTime' operator emits a value from the source Observable only after a particular time span has passed without another source emission. It is most commonly used for search input fields to prevent making an API request for every single keystroke, significantly reducing server load.

The 'distinctUntilChanged' operator suppresses duplicate consecutive items emitted by the source Observable. In Angular, it is often paired with 'debounceTime' in search logic to ensure that if a user types and then backspaces to the same value, an identical, redundant API request is not triggered.

An 'AsyncSubject' emits only the last value (and only the last value) emitted by the source Observable, and only after that source Observable completes. It is useful for representing asynchronous computations that yield a single result, similar to how a Promise behaves but within the RxJS ecosystem.

A 'Subject' has no initial value and only emits future values. A 'BehaviorSubject' requires an initial value and always emits the current/last value to new subscribers. A 'ReplaySubject' can emit a buffer of several previous values (history) to new subscribers, making it ideal for event logging or synchronization.

A Promise handles a single asynchronous event and is eager (starts immediately). An Observable handles a stream of multiple events over time and is lazy (starts only on subscription). Observables are cancellable and provide powerful operators like map, filter, and switchMap for complex transformations.

A Subject does not store any value and only emits data to subscribers who are active at the time of emission. A BehaviorSubject requires an initial value and always emits the 'current' value to any new subscriber immediately upon subscription, which is useful for state management.

Signals are a new reactive primitive in Angular (v16+) that track state changes with fine-grained precision. Unlike RxJS, which uses streams, a Signal is a producer that knows exactly which consumers (templates or effects) are using it. This allows Angular to update only specific parts of the UI without traversing the entire component tree.

Use Signals for local UI state, synchronous data, and template rendering because they are simpler and provide better performance for view updates. Use RxJS Observables for asynchronous data streams, complex event handling, and cross-component messaging where operators like 'debounceTime' or 'switchMap' are required for logic.

'signal()' creates a writable value. 'computed()' creates a read-only derived value that automatically updates when its dependencies change (lazily evaluated). 'effect()' is a function that runs automatically whenever the signals it reads change, typically used for side effects like logging or syncing with external APIs.

Signals are easier to read and write for state (no .subscribe() or .pipe() needed), they are synchronous, and they offer better performance because they enable 'local' change detection. Signals also eliminate the need for Zone.js in modern Angular apps, leading to significantly smaller and faster applications.

A Signal 'effect()' is a reactive block of code that runs whenever the signals inside it change. You should use them for 'side effects' that don't belong in the UI data flow, such as updating local storage, triggering manual DOM animations, or synchronizing data with non-Angular libraries like D3.js or Leaflet.

In signal-based change detection, Angular tracks which specific Signals are read by which components. When a Signal value changes, Angular knows exactly which components need to be re-rendered. This bypasses the traditional 'top-down' dirty checking of every component, making view updates nearly instantaneous in complex apps.

Signals provide fine-grained reactivity, allowing Angular to update only the specific parts of the DOM that depend on a piece of state. This eliminates the need for expensive top-down change detection, reduces reliance on Zone.js, and results in simpler code that is easier to reason about and debug.

You create a writable signal using the 'signal()' function, for example: 'const count = signal(0);'. You read its value by calling it like a function: 'count()'. To update it, you can use '.set(newValue)' for direct assignment or '.update(fn)' to derive a new value from the current one.

Signals are intended to become the primary reactive primitive in Angular. The framework is moving toward 'Zoneless' applications where change detection is entirely signal-based. This transition will lead to better performance, smaller bundle sizes (by removing Zone.js), and a more consistent developer experience across the entire framework ecosystem.

An Observable is a push-based stream that handles asynchronous events over time. A Signal is a synchronous state primitive that represents a value and tracks its dependencies. Signals are better for UI state, while Observables are better for event handling and HTTP requests.

A 'computed' signal is a read-only signal that derives its value from other signals. It is lazily evaluated and memoized, meaning it only recalculates if its dependencies change, making it an extremely efficient way to handle complex UI logic that depends on multiple state variables.

Signal effects are functions that run automatically when the signals they read change. You should use them for 'side effects' that don't belong in the UI rendering cycle, such as manual DOM manipulation, synchronizing data with LocalStorage, or logging state changes for debugging purposes.

HttpClient is a service provided by '@angular/common/http' for performing HTTP requests. It is built on top of the browser's XMLHttpRequest but provides a much more powerful API that returns RxJS Observables, supports request/response interceptors, and handles JSON parsing and error management automatically.

HTTP Interceptors are classes that can intercept and modify HTTP requests or responses before they are sent or received. They are commonly used for global tasks like adding authentication tokens to headers, logging request times, or handling specific error codes (like 401 redirects) in a single, centralized location.

HttpTestingController is a service used in unit tests to mock and verify HTTP requests made by the HttpClient. It allows you to intercept outgoing requests, provide 'dummy' responses, and assert that the correct URL, method, and parameters were used by the service being tested.

HTTP errors are handled in the RxJS stream using the 'catchError' operator. Inside catchError, you can inspect the error status, log it, and then either return a user-friendly fallback value or re-throw the error using 'throwError' to be handled by the component's subscriber.

Using the 'HttpClient' service, you call corresponding methods: 'http.get(url)', 'http.post(url, body)', 'http.put(url, body)', and 'http.delete(url)'. Each method returns an Observable. You then subscribe to these observables or use the async pipe in your templates to handle the asynchronous response data.

TestBed is the primary API for writing Angular unit tests. It creates a dynamic testing module that emulates an NgModule. You use it to configure the components, services, and dependencies required for a test, allowing you to instantiate components and interact with them in a controlled, isolated environment.

ComponentFixture is a wrapper around an Angular component in a test environment. It provides access to the component instance, the underlying native DOM element, and methods to trigger change detection ('fixture.detectChanges()'), allowing you to verify that the UI correctly responds to logic changes during testing.

Jasmine is a behavior-driven development framework for testing JavaScript code. It does not depend on any other JavaScript frameworks and does not require a DOM. It provides a clean, easy-to-read syntax for writing test suites (describe), test cases (it), and assertions (expect) in Angular applications.

Karma is a test runner tool that spawns a web server and executes source code against real web browsers. It allows you to run your Jasmine tests in multiple browsers simultaneously (Chrome, Firefox, Safari) and provides instant feedback by re-running tests every time a file is saved during development.

Jasmine is the testing framework that defines the syntax for your tests (the 'what' and 'how' of the testing logic). Karma is the test runner that provides the environment where those tests are executed (the 'where'—the browser). Together, they form the default testing stack for Angular projects.

You use 'TestBed' to configure a testing module. You create a 'ComponentFixture' using 'TestBed.createComponent()', which gives access to the component instance and its DOM. You then trigger change detection manually using 'fixture.detectChanges()' and use 'expect' statements to verify that the UI matches the component state.

'DebugElement' is an Angular-specific abstraction over a native DOM element. It provides a platform-agnostic way to inspect elements during testing, offering useful properties like 'componentInstance', 'attributes', and 'styles', as well as the 'query' method to find child elements using CSS selectors or directives.

You use 'TestBed.configureTestingModule' to provide mocked versions of the dependencies. You replace real services with spy objects (using Jasmine's 'createSpyObj'), ensuring that the component is tested in isolation and that tests remain fast and deterministic without making actual network calls.

Renderer2 is a service that provides an abstraction for DOM manipulation. Direct DOM access (via nativeElement) is discouraged because it bypasses Angular's security/sanitization and makes the application incompatible with non-browser environments like Server-Side Rendering (Universal) or Web Workers. Renderer2 ensures your DOM changes are platform-agnostic.

ElementRef is a wrapper around a native DOM element. You inject it when you need to access the underlying HTML element of a component or directive. While it provides direct access via the 'nativeElement' property, it should be used cautiously to avoid breaking platform abstraction and security.

ViewContainerRef represents a container where one or more views can be attached. It provides methods like 'createComponent()' to dynamically instantiate and insert Angular components into the DOM at runtime, which is the foundation for modals, dynamic tabs, and advanced UI systems.

Accessing 'nativeElement' directly couples your code to the browser's DOM. This breaks compatibility with non-browser environments like Server-Side Rendering (Angular Universal) or Web Workers. Using abstractions like 'Renderer2' or template variables ensures that your application remains portable and secure across different execution platforms.

In modern Angular, you use 'ViewContainerRef.createComponent()'. You inject 'ViewContainerRef' into the parent component, then call 'createComponent(ChildComponentType)' to instantiate and attach the child. This is the standard way to implement dynamic UIs like modals, popups, or flexible dashboard widgets that aren't hardcoded in the template.

A 'Template' is the HTML code written by the developer. A 'View' is the runtime instance generated by the Angular engine from that template. Angular uses ViewContainers to manage these runtime views, allowing for dynamic insertion and removal of UI elements during program execution.

1. 'Store' is the single source of truth for app state. 2. 'Actions' describe unique events. 3. 'Reducers' handle state transitions based on actions. 4. 'Effects' handle side effects (API calls). 5. 'Selectors' are pure functions used to slice and transform parts of the state for components.

Services are simple, flexible, and sufficient for small-to-medium apps. NgRx provides a strict, unidirectional data flow pattern (Redux) that makes state transitions predictable, traceable, and easier to debug with DevTools. Use NgRx when multiple unrelated components need to share and modify the same complex data.

Use NgRx when your application state is complex, needs to be accessed by many different components, or requires a traceable history of changes. It is ideal for large-scale applications where shared services become difficult to manage, providing a clear structure and debugging tools like the Redux DevTools.

Akita is an OOP-based state management library that focuses on simplicity and uses RxJS. NGXS is a state management pattern that uses decorators to reduce boilerplate code. Both are popular alternatives to NgRx for developers who find the standard Redux pattern too verbose or complex for their specific project needs.

The Redux pattern is a unidirectional data flow architecture where the application state is stored in a single immutable object. Changes are made by dispatching 'Actions' to 'Reducers', which calculate the next state. Components then 'Select' data from this store, making state changes predictable and traceable.

NgRx Store relies on: 1. Actions (events), 2. Reducers (state transition logic), 3. Selectors (efficient data retrieval), 4. Effects (handling side effects like HTTP), and 5. Store (the central state container). This structure ensures that component logic is decoupled from state management.

Services are simple, flexible, and use 'BehaviorSubject' to share data, but they lack formal structure. NgRx provides a strict, boilerplate-heavy architecture that enables powerful features like 'Time-Travel Debugging' and ensures state cannot be modified directly, making it better for massive, complex applications.

NgRx Effects isolate side effects from components. Instead of components calling services directly, they dispatch an action. The Effect listens for that action, performs an asynchronous task (like an API call), and then dispatches a new action with the result to update the store.

This error occurs when a component's property changes *after* Angular has already finished checking the view for that cycle. It usually happens in lifecycle hooks like 'ngAfterViewInit' if you update a value that is used in the template, violating Angular's unidirectional data flow principle meant to ensure UI stability.

First, identify which variable is causing the issue from the error trace. The fix usually involves moving the property update to an earlier lifecycle hook (like 'ngOnInit' instead of 'ngAfterViewInit'), using a microtask (setTimeout or Promise.resolve), or manually calling 'detectChanges()' after the update.

Global error handling is implemented by creating a class that implements the 'ErrorHandler' interface and its 'handleError' method. You then provide this class in your application configuration to override the default behavior, allowing you to log errors to an external service or display custom user notifications.

Angular DevTools is a Chrome/Firefox extension that provides debugging and profiling capabilities for Angular applications. It allows you to inspect the component tree, view and edit component state (properties/inputs/outputs), and profile change detection cycles to identify performance bottlenecks in real-time as you interact with the app.

Effective debugging involves using Angular DevTools for component tree inspection, Augury (legacy) or standard Chrome DevTools for source-mapped TypeScript debugging. You should also utilize the 'sourceMap: true' configuration in angular.json to map browser errors back to original code and leverage console logging within lifecycle hooks.

To debug this, first identify the property causing the issue using the stack trace. Common fixes include moving the logic to 'ngOnInit' instead of 'ngAfterViewInit', wrapping the update in a 'setTimeout()' to move it to a different task, or manually calling 'ChangeDetectorRef.detectChanges()'.

ErrorHandler is a global interface that provides a hook for centralized exception handling. By providing a custom implementation of this class, you can intercept all unhandled exceptions application-wide, which is essential for sending error logs to external monitoring services like Sentry or LogRocket.

To create a custom error handler, you define a class that implements the 'ErrorHandler' interface and its 'handleError' method. You then register this class in your 'AppModule' or application config using the '{ provide: ErrorHandler, useClass: GlobalErrorHandler }' provider definition.

Angular does not have a built-in 'Error Boundary' component like React. Instead, it uses the global 'ErrorHandler' service. However, you can simulate boundaries by using local 'try-catch' blocks within components or creating a wrapper component that catches child errors and displays a fallback UI.

Common causes include failing to unsubscribe from RxJS Observables in components, keeping references to destroyed elements in global services, using 'addEventListener' without removing it in ngOnDestroy, and capturing large objects in closures within long-running asynchronous tasks or timers like setInterval.

SSR, implemented via Angular Universal, is the process of rendering your application on the server into static HTML. When a user requests a page, the server returns the fully rendered HTML first, providing a faster 'first paint' for the user and making the content easily crawlable for search engines (SEO).

Ivy is the modern rendering engine and compiler for Angular (introduced in v9). It was designed for better build times, smaller bundle sizes (due to improved tree-shaking), and better debugging. It changed how components are compiled into instructions, making the framework much more efficient and enabling modern features like Signals.

Angular Universal is the technology that enables Server-Side Rendering (SSR) for Angular. It executes your application on the server to generate static HTML, which is then sent to the client. This improves initial load performance and ensures that the content is indexed by search engines that may not execute JavaScript.

A Service Worker is a script that runs in the background of a browser, independent of the web page. In Angular, it is used to create Progressive Web Apps (PWAs) by caching assets, enabling offline functionality, and handling push notifications. It intercepts network requests to serve content even when there is no internet connection.

Differential loading is a build-time strategy where Angular CLI generates two sets of bundles: one for modern browsers (ES2015+) and one for older browsers (ES5). Modern browsers download smaller, more efficient code, while older browsers get a polyfilled version, ensuring compatibility without penalizing users on modern systems.

A PWA is a web application that uses modern web capabilities to deliver an app-like experience to users. They are reliable (work offline), fast (smooth animations and navigation), and engaging (can be installed on the home screen and receive push notifications), all while being served via a standard web browser.

You can transform an Angular app into a PWA by running the command 'ng add @angular/pwa'. This automatically adds a service worker configuration, a web app manifest file, and icons of various sizes to your project, enabling the 'Install' prompt and offline caching capabilities immediately.

Web Workers allow you to run CPU-intensive tasks (like complex data processing or image manipulation) in a background thread, separate from the main UI thread. This prevents the browser from freezing or stuttering, ensuring that the Angular application remains responsive to user interactions during heavy computations.

Internationalization is the process of designing and preparing your project for use in different locales. In Angular, this involves marking text for translation in templates, allowing the application to be rendered in different languages and formats (dates, currency) based on the user's geographical or cultural preferences.

Angular uses the 'i18n' attribute in templates to mark strings for translation. You then use the Angular CLI to extract these strings into a translation source file (usually XLIFF). After translating, you build the application for each target locale, resulting in language-specific versions of the app.

@angular/localize is a package that provides the tools for managing translations at runtime and compile-time. It enables the use of the '$localize' tagged template string for translating text in TypeScript files, complementing the i18n template attribute and ensuring a unified localization strategy across the whole app.

Ivy's primary benefit is 'locality,' meaning the compiler only needs the component and its metadata to generate code, leading to faster rebuilds. It also generates more tree-shakable code, resulting in smaller bundles, and provides much clearer stack traces and error messages during development.

View Engine was the legacy compilation and rendering pipeline used before Ivy. It used a different internal representation of components which was less efficient for tree-shaking and resulted in larger bundles and slower build times. It has been completely replaced by Ivy in modern Angular versions.

The Component Dev Kit (CDK) provides a set of tools for building complex UI components without imposing a specific design. It handles heavy lifting like accessibility (A11y), drag-and-drop, overlays (modals/popups), and virtual scrolling, allowing developers to create highly functional custom UI components.

Zones (Zone.js) track async tasks to trigger change detection. They are being removed in favor of 'Zoneless' (Signal-based) Angular because Zone.js adds significant bundle weight, has a runtime performance overhead, and makes it difficult to pinpoint exactly where change detection is needed.

APP_INITIALIZER is a multi-provider token that allows you to run code during the Angular bootstrap process. It is commonly used to fetch configuration data from a server or initialize a library before the application fully loads and displays the UI to the user.

Angular Material is an official UI component library for Angular that implements Google's Material Design specification. It provides a set of high-quality, accessible, and performant components like buttons, cards, dialogs, and data tables, ensuring a consistent and professional look-and-feel across your entire web application.

Theming in Angular Material allows you to customize the color and typography of your components globally. It uses Sass mixins to define 'palettes' (primary, accent, warn). You can create custom themes or use pre-built ones, enabling you to align the UI with your brand's specific design guidelines easily.

You customize Angular Material components using Sass variables for colors and typography, or by overriding CSS classes using '::ng-deep' (though deprecated) or more modern approaches like CSS custom properties. You can also create custom components that wrap Material elements to enforce specific project-wide design rules.

In modern Angular, 'ng build' defaults to production settings. Historically, '--prod' enabled several optimizations: AOT compilation, minification of code and CSS, removal of comments/dead code (tree-shaking), and production environment configurations. These ensure the smallest and fastest possible bundle for deployment to a live server.

webpack-bundle-analyzer is a tool that creates a visual treemap of your application's JavaScript bundles. It shows the size of every dependency and component, helping you identify exactly which libraries are bloating your application. This is a critical tool for performance optimization and reducing the initial download time of your app.

You build for production using 'ng build'. This command executes several optimizations: it enables AOT compilation, performs 'dead code elimination' (tree-shaking), minifies JavaScript and CSS, and generates unique hash names for files to manage browser caching effectively, ensuring the fastest possible load times for users.

In newer Angular versions (v12+), 'ng build' uses the production configuration by default. Previously, '--prod' was required to enable optimizations like minification and AOT. Currently, you should check your 'angular.json' to see what configurations are applied, but the standard build is now production-ready by default.

The most effective way is using the 'webpack-bundle-analyzer'. First, build your project with the '--stats-json' flag. Then, run the analyzer against the generated 'stats.json' file. This provides a visual representation of your bundle, showing which libraries or components are contributing most to the total size.

Angular apps are static files after the build, so they can be hosted on any static web server. Common platforms include Firebase Hosting (native CLI support), Vercel, Netlify, AWS S3 with CloudFront, or traditional servers running Nginx or Apache with proper routing configurations.

Environment configuration allows you to define different variables (like API URLs or feature flags) for different build targets. Angular uses 'environment.ts' for development and 'environment.prod.ts' for production. During the build process, the CLI swaps these files based on the specified configuration in 'angular.json'.

Tree-shaking relies on ES modules and static analysis. To optimize it, ensure you provide services using 'providedIn: root', avoid importing entire libraries when you only need one function, and use the 'sideEffects: false' flag in package.json to help the build tool remove dead code.

Differential loading is a strategy where the CLI builds two versions of your app: one with modern JavaScript (ES2015+) and one with polyfills for older browsers (ES5). Modern browsers download the smaller, faster version, while older browsers remain compatible, ensuring a balance of performance and reach.

To deploy on Vercel, you connect your Git repository to the Vercel dashboard. Vercel automatically detects the Angular framework, sets the 'ng build' command and 'dist/' output folder, and provides an optimized global CDN for serving the static files with SSL enabled.

This command builds the application using the 'production' settings defined in 'angular.json'. It typically enables AOT compilation, optimization of images and CSS, minification, and sets the 'environment.ts' to the production version to ensure the app is ready for high-performance live environments.

Polyfills.ts provides code that 'fills' the gap between a browser's current JavaScript implementation and the version of JavaScript used by Angular. It ensures that modern features like Promises or Observables work correctly on older browsers that do not natively support them.

Smart components (containers) handle data fetching, state management, and interaction with services. Dumb components (presentational) receive data via @Input, emit events via @Output, and are purely responsible for rendering the UI. This pattern promotes reusability, easier testing, and a clear separation of business logic from UI structure.

Angular prevents Cross-Site Scripting (XSS) by automatically sanitizing all values used in templates through interpolation and property binding. It treats all data as untrusted by default. To safely use potentially dangerous content like HTML or URLs, you must use the 'DomSanitizer' service to explicitly trust specific values.

DomSanitizer is an Angular service used to help prevent XSS by cleaning values before they are used in the DOM. It provides methods like 'bypassSecurityTrustHtml' or 'bypassSecurityTrustResourceUrl'. You should use this service sparingly and only when you are certain the content being marked as 'safe' is actually secure.

The Angular Style Guide is a set of official best practices and conventions for developing Angular applications. It covers naming conventions, file structure, component logic, and service implementation. Following this guide ensures that codebases remain consistent, readable, and maintainable, especially in team environments where multiple developers contribute.

Key best practices include following the official Style Guide, using 'OnPush' change detection for performance, keeping components small and focused, using services for business logic, consistently using the 'async' pipe to avoid memory leaks, and leveraging 'Signals' for local state management in modern applications.

The container component pattern (also known as Smart vs. Dumb) involves separating components that handle data (Containers) from components that only display data (Presentational). Containers communicate with services and pass data down to presentational components via @Input, which makes the UI highly reusable and easier to test.

Large apps should be structured using 'Feature Modules' or 'Standalone Components' organized by domain. Use a 'Core' folder for global singletons, a 'Shared' folder for common UI elements, and separate feature folders for specific business logic. Using Nx (Mono-repo) is also recommended for massive enterprise-scale projects.

Security best practices include preventing XSS by using built-in sanitization, avoiding direct DOM access, implementing a strict Content Security Policy (CSP), using 'DomSanitizer' only when absolutely necessary, and ensuring that all sensitive logic and data validation are handled primarily on the backend server.

Sanitization is the process of inspecting untrusted values (like HTML, style, or URLs) and turning them into safe values to be inserted into the DOM. Angular sanitizes all data by default to prevent Cross-Site Scripting (XSS) attacks, protecting users from malicious scripts embedded in dynamic content.

A performance checklist includes: 1. Using AOT compilation, 2. Enabling 'OnPush' change detection, 3. Implementing lazy loading for all routes, 4. Using 'trackBy' with *ngFor, 5. Optimizing images, 6. Using Web Workers for heavy tasks, and 7. Minimizing the use of third-party libraries in the initial bundle.

Bundle size optimization involves reducing the amount of JavaScript sent to the browser. Techniques include tree-shaking (removing unused code), lazy loading modules, using lightweight alternatives for heavy libraries (like date-fns instead of moment), and ensuring that all services are provided using the tree-shakable 'providedIn: root' syntax.

The best practice is to always use 'providedIn: root' for services that are intended to be global singletons. This ensures they are tree-shakable and minimizes memory usage, as the service is only instantiated if it is actually injected into a component that is currently active.

The best practice for 'OnPush' is to use it in all 'Dumb' components. This requires passing data via immutable @Inputs. By doing so, you ensure Angular only checks these components when their inputs actually change, which is the single most effective way to optimize rendering performance.

To prevent leaks, you must always unsubscribe from observables in 'ngOnDestroy'. Best practices include using the 'async pipe' in templates, which handles cleanup automatically, or using the 'takeUntil' operator with a 'Subject' that emits when the component is destroyed.

Angular follows a strict naming convention: files use kebab-case (e.g., user-profile.component.ts), classes use PascalCase (UserProfileComponent), and selectors use kebab-case with a prefix (app-user-profile). Following these standards improves project consistency and ensures compatibility with CLI-generated code.

The feature module pattern involves grouping all related components, directives, and services for a specific domain into its own NgModule. This module is then lazy-loaded, which keeps the initial bundle size small and ensures that the codebase remains organized as the application grows.

Angular has built-in support for CSRF protection. The HttpClient looks for a cookie (usually named XSRF-TOKEN) and sets a corresponding HTTP header (X-XSRF-TOKEN). The backend must provide this cookie to the client, and Angular will automatically handle the header synchronization for all requests.

The shared folder is used to store reusable UI components (buttons, loaders), directives, and pipes that are utilized across multiple feature modules. By grouping these in a shared module, you avoid declaring them multiple times and ensure a consistent UI library throughout the application.

The core folder is designed for global, 'once-per-app' code. This includes singleton services (Auth, Logging), global interceptors, and components that only appear once like the Navbar or Footer. This ensures that global configuration is separated from feature-specific code.

Smart components are 'controllers' that know about the system state and services. Dumb components are 'pure templates' that only know about their @Inputs and @Outputs. This separation makes dumb components highly reusable across different parts of the application or even different projects.

Angular treats all values as untrusted by default. When data is bound via interpolation or property binding, Angular automatically sanitizes the data by removing dangerous HTML tags and script attributes. This built-in security layer ensures that malicious scripts cannot be executed in the user's browser.

DomSanitizer is used to explicitly mark a value as 'safe' when you intentionally want to bypass Angular's built-in security. For example, if you need to embed a trusted YouTube iframe URL, you use 'bypassSecurityTrustResourceUrl' to tell Angular not to block the potentially dangerous link.

The official Style Guide recommends a 'Fold-to-Feature' structure. You should use kebab-case for filenames, PascalCase for classes, and organize files by feature. Keep components small, extract logic into services, and maintain a clear separation between core, shared, and feature modules for long-term scalability.