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 ElementRef
In most common use cases of manipulating DOM is using directive and using nativeElementgreen. 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
Renderer2
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.
Summary
So, in this blog, we see why shouldn’t we use ElementRef for DOM manipulation. Using Renderer2 is
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.
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.
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?
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.
Pingback: itemprop="name">Stop Using ElementRef! For DOM Manipulation In Angular – ZeptoBook – Angular Questions
Pingback: itemprop="name">How To Listen Changes In Reactive Form Controls Using valueChanges In Angular - ZeptoBook
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:
https://github.com/angular/components/blob/master/src/cdk/table/cell.ts#L116
https://github.com/angular/components/blob/master/src/material/badge/badge.ts#L211nce you’re not using innerHtml, it’s safe to use nativeElement, even in Angular Universal