hardFrontend

Why use Renderer2 instead of direct DOM access?

Q: Why use Renderer2 instead of direct DOM access?

**Core concept.** Renderer2 is an abstraction over DOM manipulation. Using it (instead of touching nativeElement directly) keeps your code **platform-agnostic** — it works in server-side rendering, web workers, and other renderers — and **safer**, since it goes through Angular's sanitization and avoids direct, error-prone DOM coupling. Renderer2 browser DOM <rect class='d-box' x='170' y='104' width='120' height='34'

338 views

Understand the problem

Explain Renderer2.

renderer2dom

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Stuck? AI Nudge Available

Get a conceptual hint to guide your logic without spoiling the final implementation.

Study the solution

The solution is waiting

Give it an honest attempt first — then compare your thinking with the full walkthrough.

Read the code

Renderer2 instead of nativeElement

import { Directive, ElementRef, Renderer2, OnInit } from '@angular/core';

@Directive({ selector: '[appPin]', standalone: true })
export class PinDirective implements OnInit {
  constructor(private el: ElementRef, private r: Renderer2) {}

  ngOnInit() {
    // ✅ platform-safe (works under SSR), instead of el.nativeElement.style...
    this.r.setStyle(this.el.nativeElement, 'position', 'sticky');
    this.r.addClass(this.el.nativeElement, 'pinned');
  }
}

Join the discussion

Discussion (0)

No responses yet. Be the first to share what you think.

What is the difference between Subject, BehaviorSubject, and ReplaySubject?

How do you implement custom routing strategies by extending RouteReuseStrategy?