Angular.js: ¿Cómo puedo eliminar los comentarios creados por ng-if y ng-repeat?

Creado en 22 ago. 2014  ·  40Comentarios  ·  Fuente: angular/angular.js

¿Hay alguna forma de evitar que Angular cree comentarios HTML "auxiliares"? Por ejemplo,

<div ng-include="myTemplate"></div>
Se transformará en algo como

<!-- ngInclude: 'hurr-durr.html' -->
<div ng-include="myTemplate"></div>

¿Cómo paro esto?

$compile won't fix inconvenient

Comentario más útil

los comentarios mostrarán cierta lógica del producto que no quiero que otras personas
ver.

2014-08-26 7:05 GMT + 08: 00 Brian Ford [email protected] :

@ cc17 https://github.com/cc17 ¿por qué quieres deshacerte de estos
¿elementos? Es probable que exista una mejor manera de lograr su objetivo.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/angular/angular.js/issues/8722#issuecomment -53349716.

Todos 40 comentarios

No puedo decirle cómo funciona internamente, pero angular necesita estos comentarios para realizar un seguimiento de las directivas que pueden tener o no nodos DOM reales como salida. Por ejemplo, cuando ngIf es falso, no hay ningún nodo DOM, pero el compilador angular necesita el comentario para saber en qué posición del árbol se encuentra la directiva. Estoy seguro de que alguien más, por ejemplo @caitp, puede explicar esto mejor.

@ cc17 ¿por qué quiere deshacerse de estos elementos? Es probable que exista una mejor manera de lograr su objetivo.

los comentarios mostrarán cierta lógica del producto que no quiero que otras personas
ver.

2014-08-26 7:05 GMT + 08: 00 Brian Ford [email protected] :

@ cc17 https://github.com/cc17 ¿por qué quieres deshacerte de estos
¿elementos? Es probable que exista una mejor manera de lograr su objetivo.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/angular/angular.js/issues/8722#issuecomment -53349716.

Estuve de acuerdo con @ cc17. Incluso yo quiero lograr lo mismo.

@ cc17 Me gustaría entender esto. Angular necesita que estos nodos de comentarios estén presentes por razones que están fuera de este tema.
Ahora dijiste

los comentarios mostrarán cierta lógica del producto que no quiero que otras personas vean

Estas diciendo eso

  • ¿Le gustaría que los nodos de comentarios no muestren ninguna información? Es decir, si estos fueran nodos de comentarios vacíos, estaría bien
  • Los nodos de comentarios no deberían estar allí en absoluto

Si está hablando de la primera opción, creo que podría ser una exageración, pero existe la posibilidad de que se pueda agregar una suscripción. Si está hablando de la segunda opción, eliminarlos implicaría una gran refactorización sobre cómo funciona la transclusión de directivas y dudo que eso suceda pronto.

@lgalfaso

¿Le gustaría que los nodos de comentarios no muestren ninguna información? Es decir, si estos fueran nodos de comentarios vacíos, estaría bien

Podría decir que sería una opción.

@lgalfaso sí, la primera opción está bien. Exponga el cuerpo de comentario esencial que no romperá el comportamiento de las directivas actuales.

Vine aquí buscando las mismas respuestas al mismo problema, pero por diferentes razones (fue realmente molesto depurar los elementos DOM con un millón de comentarios en el camino).

Escuchar a otras personas describir la dependencia de Angular de los comentarios, tiene sentido. Para agregar mis dos centavos a su preocupación por ocultar la lógica de la aplicación ... Angular es javascript y, como todos sabemos, no hay forma de proteger realmente su código javascript de los usuarios que realmente quieren ver lo que tiene bajo el capó. Eliminar los comentarios, en mi opinión, solo evitaría que los mirones casuales vean tu lógica. No disuadirá a un atacante, y me sorprendería mucho si un atacante incluso considerara sus comentarios angulares como la ruta para encontrar una posible exposición o debilidad en su código.

@ cc17
"Los comentarios mostrarán alguna lógica de producto que no quiero que otras personas vean".
? Para ver los comentarios debe abrir las herramientas de desarrollo del navegador.
¡Allí, se muestra TODA la lógica de su producto (parte frontal)! Su html (original y actual), javascript, solicitudes de red ...

@seavor
"Fue realmente molesto depurar los elementos DOM con un millón de comentarios en el camino"
Me pregunto qué página angular (con un tiempo de respuesta aceptable ;-)) puedes crear generando "un millón de comentarios"

+1

También me gustaría ver una opción para eliminar comentarios del HTML en vivo. Para mis ojos es feo y molesto. A diferencia de mi editor de texto, la consola del desarrollador tiene un tercio de la página, por lo que estos comentarios adicionales realmente son un error.

¿Hay más detalles sobre por qué exactamente Angular los necesita?

Feo y que distrae no es una razón muy poderosa. 😉
Los comentarios son usados ​​por angular como marcadores para el contenido que será
insertado allí. Por ejemplo, los elementos ngIf que no se muestran necesitan esto.
Así que no creo que exista una posibilidad realista de que alguna vez lo sean
remoto. Angular 2 teóricamente debería tener el mismo problema, pero tal vez sea
diferente allí.
Am 10.02.2016 19:16 schrieb "Alistair G MacDonald" < [email protected]

:

+1

También me gustaría ver una opción para que los comentarios se eliminen del HTML en vivo.
Para mis ojos es feo y molesto.

¿Hay más detalles sobre por qué exactamente Angular los necesita?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/angular/angular.js/issues/8722#issuecomment -182509708
.

Sí, ng2 también tiene comentarios para las directivas estructurales. (Creo que estaban usando elementos <script> , pero cambiaron a comentarios en algún momento, porque los elementos estaban rompiendo los selectores CSS iirc).

Sí, entendido @Narretz , la fealdad puede no ser muy motivadora, pero no está claro cuál fue / es la compensación real. ¿Funciona mejor utilizando nodos DOM existentes? No puedo imaginarme que eso haría una gran diferencia (tal vez estoy muy equivocado). ¿O fue más fácil iterar a través de los nodos DOM en lugar de crear una matriz de JavaScript?

@ F1LT3R , los nodos de comentarios están ahí como marcadores. Son necesarios para el caso en que no se muestran los contenidos (por ejemplo, una expresión ngIf que se evalúa como falsa, un ngSwitchWhen que no coincide con la expresión ngSwitch actual, etc.). En ese caso, necesitamos un marcador de posición en el DOM para saber dónde insertar los elementos reales más adelante (por ejemplo, cuando la expresión ngIf evalúa como verdadera, etc.).

Espero que haya una opción para eso.

Dejando un comentario como este, creo que no es una buena idea.
<!-- ngIf: transaction.status==9 && transaction.status!==8 -->

@codetrash , si tienes una idea mejor que proponer, somos todos oídos: smiley:

@codetrash ¿

@Narretz para una aplicación bastante sensible como banca, servicio de pago, etc. dejando esto

!-- ngIf: transaction.status==9 && transaction.status!==8 -->

podría conducir a una situación de riesgo.

@gkalpak tal vez Dejando un marcador encriptado, etc. ¿Tienes alguno?

@codetrash El marcado de la expresión se basa en su código javascript que, de todos modos, está expuesto al agente de usuario. La confusión de su código Javascript puede dificultar la obtención de la información, pero la lógica de su aplicación aún se puede extraer. Por supuesto, podríamos intentar eliminar / ofuscar la expresión, pero personalmente creo que aquí no hay riesgo de seguridad y es de baja prioridad. Si alguien quiere intentarlo, es bienvenido, aunque no puedo garantizar que se fusionará.

Gracias @gkalpak , tiene sentido. Pude ver por qué intentar rastrear los cambios DOM en JS podría ser poco práctico para el rendimiento y la capacidad de mantenimiento. Supongo que si pudiéramos decir "Angular controla todas las cosas en el DOM", podría ser algo más factible, pero Angular tiende a mezclarse con todo tipo de bibliotecas de terceros, así que ... eh. El menor de los males".

@codetrash
<podría conducir a una situación de riesgo >>
?? Este código no es nada más que pueda leer en el html enviado en texto claro en la primera etapa de todos modos, así que ...

+1.

@smurugavel Por favor, no se

@Narretz , como dijo @ cc17 , la lógica de negocios era mi preocupación, eso no necesita ser visto por otros que pueden ver el código fuente a través de herramientas de desarrollo.
Siguiendo las sugerencias de este hilo, la primera opción de
Alternativamente, ¿puede el equipo angular encriptar estos comentarios que un humano no puede leer o agregar un identificador único que angular pueda rastrear internamente? solo mis pensamientos ..

@smurugavel , como ya se mencionó en este hilo, estos comentarios no contienen nada que no sea visible como texto sin formato en sus plantillas. Quien pueda ver su código fuente, podrá ver esta lógica empresarial. Deshacerse de los comentarios no resolverá su problema.

Espero que haya una opción para eliminar y obtener esto nuevamente en la filtración.

Dejando un comentario como este, creo que no es una buena idea.

¿Qué más si tengo que aplicar el filtro y usar ul li nuevamente en este momento, mi valor de li comentado aparece nuevamente a la vista?

@ManishLSN , no estoy seguro de lo que quieres decir. No hay comentarios li . Solo un comentario HTML simple.
Dicho esto, creo que tendría sentido tener comentarios vacíos cuando debug info está deshabilitado (el contenido de los comentarios no tiene otro propósito que "debugabilidad").

WDYT @Narretz , @lgalfaso ?

Nuevamente (para las personas que plantearon esta inquietud), esto no tendrá ningún impacto en la seguridad.

Necesitamos que los nodos de comentarios estén en el DOM o Angular simplemente no funcionará.
Podemos implementar la idea de eliminar el texto del comentario si debugInfo está deshabilitado. Este es un cambio bastante sencillo. PRs alguien?

Gracias !!!

@codetrash Esto está cerrado y creo que es bueno para "ocultar" la lógica al inspector. Pero como se indicó anteriormente, su HTML simple y JS se sirven al navegador, por lo que no debe considerarse de ninguna manera como más seguro. Esto probablemente podría protegerse mucho mejor utilizando angular del lado del servidor con 2.0. En cualquier caso, la única "situación de riesgo" que pude ver es si podrían cambiar los valores en el inspector y ver o guardar datos que no deberían poder, pero esto podría detenerse al no proporcionar esos datos al modelo en El primer lugar. Se debe considerar una mala práctica enviar datos confidenciales desde el servidor si se deben ocultar al usuario; en otras palabras, los permisos deben hacerse cumplir en el lado del servidor, especialmente para la banca, el servicio de pago, etc. Todo lo que se envíe al navegador debe ser considerado disponible públicamente.

Ese es un caso de uso interesante, Akuno. Puedo establecer por qué sería eso
frustrante.

Creo que, en la práctica, querrá filtrar ciertos elementos incluso en un
escenario no angular. Yo marcos, comentarios, etc.

Más trabajo para implementar, sí, pero una canalización más limpia y controlable
entre un formato y otro probablemente sea una buena idea.
El 25 de marzo de 2016 a las 2:55 a. M., "Akunno" [email protected] escribió:

Espero entender esto correctamente, porque estoy en un barco similar.

Actualmente mi dom contiene muchos comentarios e imágenes como esta:

cuando llamo innerHTML en el padre del elemento, termino con algo
como esto:

ng-src = "datos: imagen / gif; base64, ....">

No conozco una forma de extraer el HTML sin las directivas angulares.
Estoy tratando de extraer el HTML renderizado sin angular porque estoy pasando
esto a un convertidor que crea un documento de palabra a partir de él. Actualmente la palabra
doc contiene un montón de etiquetas de imagen con X rojas porque todavía está intentando
para renderizar la imagen como si fuera una imagen. Los comentarios también son masivos
aumentando el tamaño de la cuerda.

Intenté eliminar los comentarios, pero todavía no puedo encontrar una manera
para extraer el HTML renderizado sin que las directivas angulares lo contaminen.
Idealmente, cuando llamo innerHTML, quería ver Si el
ngIf era verdadero o alternativamente nada, si ngIf devolvió falso.

Espero haber entendido esto correctamente y que, de alguna manera, este sea un +1
para extraer de alguna manera la salida renderizada sin comentarios / directivas.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/angular/angular.js/issues/8722#issuecomment -201172995

otro caso de uso: al menos omitir nuevas líneas por configuración para css: pseudo https://css-tricks.com/almanac/selectors/e/empty/

@mashpie se encontró con el mismo caso de uso hace un momento, qué coincidencia

Angular no agrega nuevas líneas alrededor de los comentarios del marcador. Ver http://plnkr.co/edit/z1rJZd7yU0TYZmDAynTh?p=preview

Puedes hacerlo usando.

app.config (['$ compileProvider', function ($ compileProvider) {
// deshabilitar la información de depuración
$ compileProvider.debugInfoEnabled (falso);
}]);

@RHanmant esto no elimina los comentarios por completo, solo elimina los nombres de variables / propiedades de los comentarios. Los comentarios son necesarios.

Llegué a este informe de problemas cuando intentaba usar una regla css como #mydiv > div:last-child y el div que debería ser el último hijo no se debía al comentario de angularjs posterior.

Los selectores de CSS ignoran los comentarios, por lo que lo que describió no puede suceder.

Espero que haya una opción para eso.

Dejando un comentario como este, creo que no es una buena idea.
<!-- ngIf: transaction.status==9 && transaction.status!==8 -->

Sí, todos sabrán que el desarrollador fue demasiado vago para agregar algunas constantes en lugar de codificar valores :).
Y sí, hay un poco de divulgación (porque está en la interfaz), pero si desinfectó el respaldo a fondo, nadie explotará esta información "filtrada". Así que creo que deberíamos centrarnos en esa parte.

¿Fue útil esta página
0 / 5 - 0 calificaciones