Stop Using ElementRef! For DOM Manipulation In Angular
Photo: Google

Stop Using ElementRef! For DOM Manipulation In Angular

Today, I am going to write on a small but important topic of DOM manipulation. DOM manipulation is much easier in all versions of Angular 2+. Angular abstract the DOM and gives you the shallow copy to mess around it. It becomes more interesting with TypeScript because your editor can hint most of the DOM property method for you.

ElementRef: Easy but unsafe way of DOM Manipulation

One of the common way of manipulating DOM is using ElementRef.

ElementRef is a wrapper around a native element inside of a view.

For example, let’s see, how to use ElementRef to change the color of an element by using the color directive.

In most common use cases of manipulating DOM is using directive and using the nativeElement property. Here, you can see, we have set the color to green. It will change the color of the element, where this directive will be applied. That’s cool!, but it is not safe as per Angular docs. See (ElementRef: Security Risk)

Security Risk

As per Angular docs, ElementRef has direct access to DOM, and it makes your application more vulnerable to XSS attacks. Use this, when you have no option left to access the DOM element.

Also, direct DOM access creates tight coupling between your application and rendering layers which will make it impossible to separate the two and deploy your application into a web worker.

Renderer2: Safer way of DOM Manipulation

The Renderer2 class is an abstraction provided by Angular in the form of a service that allows to manipulate elements of your app without having to touch the DOM directly. This is the recommended approach because it then makes it easier to develop apps that can be rendered in environments that don’t have DOM access, like on the server, in a web worker or on native mobile.

Let’s modify our above example now by using Renderer2 and make our app safer.

And everything will work as expected. You can read more about Renderer2 by clicking on below link.

Angular Renderer2


So, in this blog, we see why shouldn’t we use ElementRef for DOM manipulation. Using Renderer2 is safer way of DOM manipulation than ElementRef.

Further Reading


Hi, I am Adesh. I am a senior software engineer having more than 12 years of software development experience. I am a full stack developer and interested in writing the technical post on programming. I am currently working in New York City area.

This Post Has 7 Comments

  1. Entomo

    This is completely wrong. You shouldn’t be manipulating the DOM from typescript at all. Ever. You should be using variables where changes get automatically propagated to the template.

    1. Shawn

      That’s a little declarative, Entomo. There are times — drawing to a canvas is one example — where DOM interaction and manipulation is necessary from Typescript. This is why tools like HostBinding or ViewChild exist. Should you avoid it when possible for security and performance? Of course. But to say that it should *never* be done ignores large swaths of real-world use cases in business.

  2. Matt

    I would add that an acceptable use of ElementRef is for targeting elements with a jquery plugin. I don’t think Renderer2 helps you in this way but would be curious to know if that’s the case?

  3. Vincent

    You’re wrong you should use Renderer2 to manipulate element style along with elementRef. In fact if you bypass this usage, you may end up with twist like that to make it work.

  4. Dave

    The Angular team were very vocal against the use of nativeElement early on, but they’ve changed their attitude since then (although not the documentation)

    If you look at the Angular Material codebase, you won’t find any reference to Renderer2, but plenty of use of nativeElement. See here for examples: you’re not using innerHtml, it’s safe to use nativeElement, even in Angular Universal

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.