Donde hacemos la lectura ( get ) y escribir ( get ) determina en gran medida cuánto costo pagamos por el rendimiento.

set términos

Se llama a una función set ter cada vez que escribimos algún valor.

Ahora generalmente hacemos la parte de escritura que llama a los set en nuestras clases de TypeScript. Por lo tanto, no los llaman tan a menudo a menos que haya una operación set , que no es muy frecuente en general.

get ters

Se llama a una función get ter cada vez que leemos algún valor.

Los get ters generalmente se llaman en plantillas en diferentes sintaxis de enlace de datos como interpolación de cadenas ( {{}} ), enlace de propiedades ( [---]="" ), enlace de atributos ( [attr.---]="" ), enlace de estilo ( [style.---]="" ), etc.

Ahora, el problema con esto es que, cada vez que Angular realiza la detección de cambios, get llama a los captadores. Está bien siempre que no haya mucha lógica en su get ter. Pero eso aún deja un espacio para que los desarrolladores más nuevos en el equipo agreguen lógica allí sin ser conscientes de los impactos de rendimiento que creará.

Entonces, en resumen, por lo que entiendo, está bien tener set ters. Pero get getters y su costo en el rendimiento dependería principalmente de dónde get usen esos getters. Si se usan en una de las sintaxis de enlace de plantilla, es seguro NO TENERLAS EN PRIMER LUGAR. Si no se usan en la plantilla, está bien tenerlos.

De hecho, he escrito un artículo y algunas respuestas sobre varios subprocesos de StackOverflow que quizás también desee consultar. Así que los estoy agregando como una lista a continuación:

1. Angular: evitar que DomSanizer se actualice en eventos DOM

2. Rendimiento angular: ngStyle vuelve a calcular cada clic en una entrada aleatoria

3. Angular 7, respuesta lenta de formulario reactivo cuando tiene grandes datos

4. Rendimiento angular: el evento DOM provoca llamadas de función innecesarias

5. Cambié mi implementación de una forma reactiva angular EXTREMADAMENTE profundamente anidada y no creerás lo que sucedió 🤯

Espero que esto te dé alguna perspectiva. :)

evite getters específicamente si es posible. Los captadores tienen un efecto negativo en la detección de cambios. Para saber si la vista debe actualizarse, Angular necesita acceder al nuevo valor, compararlo con el anterior y tomar la decisión de si la vista debe actualizarse. Por esta razón, el valor se compara y actualiza en cada ciclo de detección de cambios. Esto puede causar problemas de rendimiento y evita ciertas configuraciones como OnPush. Si por alguna razón necesita transformar datos cuando se cambia un @Input() en un componente, un setter está bien, por ejemplo.

 value; @Input('myValue') set myValue(v) { transformValue(v); } transformValue(v) { ...*sometransform* this.value = transforrmedValue }

en este ejemplo, se coloca un setter en la entrada y el valor se transforma cada vez que se inserta un nuevo myValue en el componente. Sin embargo, si se introduce un getter, el componente verificará el getter cada vez que cambie los ciclos de detección de todos modos. También podría usar otras cosas como tuberías o ngOnChange en lugar de setters.

ACTUALIZAR

siempre que su componente esté usando ChangedetectionStategy.OnPush ahora usar un getter está bien, pero evítelo si no está usando OnPush

Esta es en parte una opinión, en parte los requisitos de su solicitud. Ciertamente no es malo usar getters y setters. Pero también los usaría con discreción y, en la mayoría de los casos, los getters y setters pueden ser innecesarios.

En el código de ejemplo que proporciona, no hay razón para usar un getter y setter. Tiene razón en que puede ayudar cuando se realiza algún tipo de verificación de validación o cuando algo más depende del valor que se establece, etc. Por ejemplo, tal vez necesite llamar a alguna función cuando una propiedad @Input() cambia de valor, esto puede ser una manera fácil de lograr eso. Pero en muchos casos, esto probablemente no sea un requisito para cada variable/entrada en su aplicación.

Espero que esto ayude.