Decorators

@ViewChild queries elements defined in the component's own template. @ContentChild queries elements projected into the component from outside using ng-content. @ViewChild references are available in ngAfterViewInit while @ContentChild references are available earlier in ngAfterContentInit. Both support the static option for earlier access.

// ViewChild: queries own template
@ViewChild('myInput') input!: ElementRef;

// ContentChild: queries projected content
@ContentChild(HeaderComponent) header!: HeaderComponent;

// In parent template
<app-card>
  <app-header>Projected!</app-header>  <!-- queried by ContentChild -->
</app-card>

Think of ViewChild as querying your own template and ContentChild as querying what others put inside your component tags.

Why it matters: Tests understanding of template vs projected content. Shows you know component composition patterns.

Real applications: ViewChild accesses form inputs or child components you created. ContentChild accesses elements the parent projected in using ng-content.

Common mistakes: Developers mix up which decorator to use. They can't find projected content because they use @ViewChild. They think @ContentChild queries only direct children.

@Optional tells Angular that a dependency is not required and should not throw an error if it cannot be found. Without @Optional, Angular throws a NullInjectorError if the dependency is not provided anywhere in the injector tree. With @Optional, Angular simply injects null instead. This is useful for optional features or plugins.

constructor(
  @Optional() private analytics: AnalyticsService
) {}

trackEvent(name: string) {
  // Only track if analytics service is available
  this.analytics?.track(name);
}

Always check for null before using optional dependencies. Use the optional chaining operator (?.) for safe access.

Why it matters: Tests understanding of optional dependencies. Shows you can handle gracefully missing services.

Real applications: Optional analytics services, feature-specific services that may not be installed, plugin architectures, testing with optional mocks.

Common mistakes: Developers don't use @Optional causing injection errors. They forget null checks on optional dependencies. They use optional for everything instead of just truly optional features.

@Pipe decorator marks a class as an Angular pipe and gives it a name that can be used in template expressions. Every pipe class must implement the PipeTransform interface with a transform method. The name property defines the identifier used in templates with the pipe operator (|). Set pure to false for impure pipes that run on every change detection cycle.

@Pipe({
  name: 'truncate',
  standalone: true,
  pure: true // default
})
export class TruncatePipe implements PipeTransform {
  transform(value: string, limit = 50): string {
    return value.length > limit ? value.substring(0, limit) + '...' : value;
  }
}

// Usage: {{ longText | truncate:30 }}

Pipes can be standalone by setting standalone: true for use without NgModules. Pure pipes are more performant as they only run when input values change.

Why it matters: Tests understanding of pipe creation and optimization. Shows you can extend template functionality.

Real applications: Date pipes with custom formats, currency pipes with specific locales, text transformation pipes (uppercase, truncate), filter pipes.

Common mistakes: Developers create impure pipes unnecessarily harming performance. They forget to implement PipeTransform. They don't understand the pure flag changes when pipe runs.

@Attribute injects the value of an HTML attribute from the host element as a simple string. Unlike @Input, it only reads the attribute once at creation time and does not track changes. It is useful for static configuration values that never change. Since it does not create a binding, it is slightly more performant than @Input for pure string constants.

@Component({ selector: 'app-button' })
export class ButtonComponent {
  constructor(@Attribute('size') public size: string) {
    console.log(size); // 'large'
  }
}

// Usage: <app-button size="large"></app-button>
// Note: size is read once, NOT bound. [size]="var" won't update it.

The value is always a string or undefined. Use @Input instead if you need dynamic values that change over time.

Why it matters: Tests understanding of static vs dynamic attribute binding. Shows you know performance and change detection implications.

Real applications: Reading data attributes for configuration, reading custom attributes set by build tools, settings that never change during component lifetime.

Common mistakes: Developers use @Attribute for dynamic values then wonder why they don't update. They forget it's read at creation time only. They use @Attribute when plain @Input would work.

@Component is actually a subclass of @Directive with additional template-related metadata. @Directive creates directives that modify the behavior of existing elements without their own view. @Component creates directives that have their own template and view. Both support inputs, outputs, host bindings, lifecycle hooks, and dependency injection.

// Directive: adds behavior to existing elements
@Directive({ selector: '[appHighlight]' })
export class HighlightDirective {
  @HostListener('mouseenter') onHover() { /* highlight logic */ }
}

// Component: has its own template and view
@Component({
  selector: 'app-card',
  template: '<div class="card"><ng-content></ng-content></div>'
})
export class CardComponent { }

Use @Directive when you want to add behavior to existing elements. Use @Component when you need a reusable UI element with its own template.

Why it matters: Tests understanding of decorator hierarchy and when to use each. Shows you can build both reusable components and attribute behaviors.

Real applications: Directives: [appHighlight], [appDebounce], [appClickOutside]. Components: , , .

Common mistakes: Developers use @Component when @Directive would suffice losing reusability. They add templates to directives unnecessarily. They don't understand @Component extends @Directive functionality.