0

I keep hearing all the time that it is forbidden to touch the DOM directly in Angular, but I don't understand why and how we can avoid this?

I just don't think it's possible because at some point you will use a third party plugin. And this plugin will access the DOM directly, so what is the point?

The best practice is always to use decorators like ViewChild, ContentChild, etc.

For example, someone at Reddit also wrote this.

ng2user
  • 1,997
  • 6
  • 22
  • 30
  • The "Some guy told me X, why did he?" kind of questions tend to be difficult to answer. You might get better information if you edit the question and include a literal quote from some reputable source (manual, tutorial, article...), together with a link. Just my opinion :) – Álvaro González Jun 06 '17 at 10:58
  • 1
    The reason I did not do this is because it is known to every Angular developer. – ng2user Jun 06 '17 at 10:59
  • 3
    It is because direct DOM manupilation doesn't go well with server-side rendering (AoT). If you use direct DOM accessors like `window`, it might not refer to something relevant on the server-side code (in some cases). – eko Jun 06 '17 at 11:01
  • 1
    It can't always be avoided. The underlying concept though is to reset people's thinking that are used to always manipulating the dom first...instead of having data models drive the view – charlietfl Jun 06 '17 at 11:02
  • 3
    The Angular team had a strong opinion during alpha, beta, and early final 2.0 release phase to avoid direct DOM manipulation. Because there are many developers out there who don't care about web workers or server-side-rendering they weakened their stance. Not at least because web worker (and AFAIK also server-side-rendering) support is still experimental. If you don't use any of these and don't intent to do later for your project, just access the DOM if there is no straight-forward way to achieve what you need. – Günter Zöchbauer Jun 06 '17 at 11:05
  • It's not "forbidden". If you keep the DOM manipulation within the component / directive it's not even that likely to cause errors. But it's usually the long way around compared to letting angular do the work. – Daniel Beck Jun 06 '17 at 11:06
  • @DanielBeck can you explain more what you mean by saying "If you keep the DOM manipulation within the component / directive it's not even that likely to cause errors" – ng2user Jun 06 '17 at 11:08
  • @GünterZöchbauer the usage of ElementRef is considering safe? – ng2user Jun 06 '17 at 11:16
  • 1
    @ng2user it depends on what you consider safe. If you're using the non-Angular JS libraries, then you're out of Angulars sandbox already. Angular uses default security and sanitisation for normal Angular code. If you're using `ElementRef.nativeElement` you need to ensure yourself that you don't open you app for XSS or similar. Using `ElementRef.nativeElement` by itself isn't unsafe at all, but it enables you to do stuff that can cause security issues. – Günter Zöchbauer Jun 06 '17 at 11:38
  • @ng2user I'm more familiar with angular 1 terminology, so I might be losing a bit in translation -- in angular 1 if a directive's link function does some fiddling around with the DOM, it's safe(ish) so long as it only modifies the part of the DOM drawn by that particular directive. If you start meddling with DOM nodes drawn by other directives, it's not safe at all (because you're creating dependencies between directives outside the Angular lifecycle.) Same logic in angular 2, just different terminology. – Daniel Beck Jun 06 '17 at 12:23
  • But even within a single directive or component, directly modifying the DOM usually means more effort, more fragile code, and harder to reason about code. Much better to let the template respond to changes in scope data. TL;DR let angular do what it's good at, don't get in its way by trying to do the work for it. – Daniel Beck Jun 06 '17 at 12:26

0 Answers0