The @Component decorator attaches metadata to a TypeScript class so Angular can treat it as a component. This metadata tells Angular how to render the view (template + styles), how to match it in HTML (selector), what dependencies it can use (imports/providers), and how to run it (change detection, encapsulation, host bindings). Angular needs this because a plain class doesn’t contain enough information to compile and instantiate a UI component.
What metadata does @Component provide, and why does Angular need it?
Preparing for interviews?
Use guided tracks for structured prep, then practice company-specific question sets when you want targeted interview coverage.
Quick Answer
Answer
Overview@Component({...}) is configuration for Angular’s compiler/runtime. It turns a plain class into something Angular can: (1) match in templates, (2) compile into render instructions, and (3) instantiate with the right DI scope and runtime behavior.
TYPESCRIPT
import { Component, ChangeDetectionStrategy, ViewEncapsulation } from '@angular/core';
@Component({
selector: 'app-user-card',
standalone: true,
imports: [],
template: `
<article class="card">
<h3>{{ name }}</h3>
</article>
`,
styles: [`.card { padding: 12px; }`],
changeDetection: ChangeDetectionStrategy.OnPush,
encapsulation: ViewEncapsulation.Emulated,
providers: [],
host: { '[class.highlight]': 'highlight' }
})
export class UserCardComponent {
name = 'Ada';
highlight = false;
}
Metadata field | What it tells Angular | Why it matters |
|---|---|---|
| How this component is referenced in templates (e.g. | Without it, Angular can’t match your class to an element in the DOM/template. |
| The view structure to compile and render. | Angular compiles it into efficient render instructions; the class alone has no view. |
| The component’s CSS. | Angular can scope/apply styles according to encapsulation settings. |
| Which directives/pipes/components are available in this template (standalone world). | Defines template dependency scope; missing imports means compile/runtime errors. |
| DI providers scoped to this component subtree. | Controls service lifetime/scope (component-level instances vs root singletons). |
| How Angular runs change detection for this component. | Affects performance + update semantics (e.g., |
| How styles are scoped (Emulated/None/ShadowDom). | Prevents style bleeding (or intentionally allows it). |
| Host bindings/listeners and composition on the host element. | Lets Angular wire DOM behavior without manual imperative DOM code. |
| Animation triggers available for this component. | Angular needs to register triggers so the runtime can execute them. |
Why Angular needs this metadata
A component is not “just a class” in Angular. Angular must know: (1) what DOM tag/selector maps to this class, (2) what template to compile, (3) what dependencies are allowed in that template, (4) what DI scope to use, and (5) how to run runtime behaviors like change detection and style scoping. None of that is inferable reliably from TypeScript code alone.
Angular uses metadata to... | Concrete outcome |
|---|---|
Compile templates (AOT/JIT) into render instructions | Fast runtime rendering; template errors are caught early in AOT builds. |
Create an internal component definition (Ivy) | Angular generates internal definitions (e.g., the compiled component factory/definition) that drive creation + updates. |
Resolve template dependency scope | Standalone |
Build the DI boundary | Component-level |
Apply runtime policies |
|
Summary
@Component metadata is the contract between your class and Angular’s compiler/runtime: how to find it (selector), how to render it (template/styles), what it can use (imports/providers), and how it behaves (changeDetection/encapsulation/host). Angular needs it because the framework must compile and instantiate UI components deterministically.
Similar questions
Guides