3

I know it is not recommended to use replace elementRef.nativeElement and it is recommended to replace iT with some tag of ViewChild or something of the sort. I wonder how can I use these tags to replace the use of it, when I have a native element of a general type. I need to access the id of a general element of an unknown type:

elmentRef.nativeElement.id

my relevant package.json:

"@angular/common": "4.2.5",
"@angular/compiler": "4.2.5",
"@angular/core": "4.2.5"

I am trying to replace this code which is a parent for may others on my library because I am getting:

import { ElementRef } from '@angular/core';

export abstract class IdentityComponent {
    id = '';

    constructor(protected el: ElementRef) {
        if (el) {
            this.id = el.nativeElement.id;
        }
    }
}
Moutabreath
  • 184
  • 1
  • 6
  • 19
  • 1
    What do you need/want the ID for? –  Oct 12 '17 at 16:27
  • To differentiate between same type components. For example, when I have multiple tabs – Moutabreath Oct 12 '17 at 16:38
  • So once you know the ID of a tab, what are you then doing with it? If you show us the code in question, we can suggest how to handle with it IDs, which as I mentioned in my answer are almost never necessary or a good idea. –  Oct 12 '17 at 16:40
  • It appears that without it, all the components that inherit from it, which are every text input that I have, don't have any id associated with it resulting in all inputs on the same page having the same id – Moutabreath Oct 16 '17 at 07:35

2 Answers2

5

I did some research and finally got to an answer, accessing elementRef through renderer is the better approach in angular 2/4 .

The Angular 2 renderer allows you to safely use elements created in your template regardless of the platform you’re working on. It’s important to remember that your components could easily be used inside a ServiceWorker or other platform, so you should always rely on the renderer to keep your DOM access safe.

Using ElementRef doesn't directly make your site less secure. The Angular team is just saying "Hey, you may use this, just be careful with it".

If you are only using an ElementRef to get information, like in your example a certain width, there is no security risk involved at all. It's a different story when you use an ElementRef to modify the DOM. There, potential threats can arise. Such an example could be:

@ViewChild('myIdentifier')
myIdentifier: ElementRef

ngAfterViewInit() {
  this.myIdentifier.nativeElement.onclick = someFunctionDefinedBySomeUser;
}

The problem with this is that it gets inserted directly into the DOM, skipping the Angular sanitisation mechanisms. What are sanitisation mechanisms? Usually, if something in the DOM is changed via Angular, Angular makes sure it's nothing dangerous. However, when using ElementRef to insert something into the DOM, Angular can't guarantee this. So it becomes your responsibility that nothing bad enters the DOM when using ElementRef. An important keyword here is XSS (Cross-Site Scripting).

To summarise: If you poll the DOM for information, you are safe. If you modify the DOM using ElementRef, make sure the modifications don't possibly contain malicious code.

Let me know if this helps

Yashwanth Potu
  • 346
  • 4
  • 19
0

Rather than wondering how to replace the use of elementRef, you should ask why it is necessary in the first place. We need to understand why you, or the previous programmer, needed the ID of the element, and what they were doing with it. In general, it's almost never necessary in Angular to deal with IDs. Usually the existence of ID-based logic indicates some kind of design anti-pattern, often to do jQuery-like DOM manipulation.

By the way, it is also bad practice to use inheritance in this way to mix in a bit of logic to your components.