Angular.js: comment puis-je supprimer les commentaires créés par ng-if et ng-repeat ?

Créé le 22 août 2014  ·  40Commentaires  ·  Source: angular/angular.js

Existe-t-il un moyen d'empêcher Angular de créer des commentaires HTML « d'aide » ? Par example,

<div ng-include="myTemplate"></div>
Se transformera en quelque chose comme

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

Comment puis-je arrêter cela?

$compile won't fix inconvenient

Commentaire le plus utile

les commentaires montreront une logique de produit que je ne veux pas d'autres personnes
voir.

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

@cc17 https://github.com/cc17 pourquoi voulez-vous vous en débarrasser
éléments? Il existe probablement une meilleure façon d'atteindre votre objectif.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/angular/angular.js/issues/8722#issuecomment -53349716.

Tous les 40 commentaires

Je ne peux pas vous dire comment cela fonctionne en interne, mais angular a besoin de ces commentaires pour garder une trace des directives qui peuvent ou non avoir des nœuds DOM réels en sortie. Par exemple, lorsque ngIf est faux, il n'y a pas de nœud DOM, mais le compilateur angulaire a besoin du commentaire pour savoir à quelle position dans l'arbre se trouve la directive. Je suis sûr que quelqu'un d'autre, par exemple @caitp, peut mieux expliquer cela.

@cc17 pourquoi veux-tu te débarrasser de ces éléments ? Il existe probablement une meilleure façon d'atteindre votre objectif.

les commentaires montreront une logique de produit que je ne veux pas d'autres personnes
voir.

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

@cc17 https://github.com/cc17 pourquoi voulez-vous vous en débarrasser
éléments? Il existe probablement une meilleure façon d'atteindre votre objectif.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/angular/angular.js/issues/8722#issuecomment -53349716.

Je suis d'accord avec @cc17. Même moi, je veux atteindre la même chose.

@cc17 J'aimerais comprendre cela. Angular a besoin que ces nœuds de commentaires soient présents pour des raisons extérieures à ce sujet.
Maintenant, tu as dit

les commentaires montreront une logique de produit que je ne veux pas que les autres voient

Êtes-vous en train de dire que

  • Vous aimeriez que les nœuds de commentaires n'affichent aucune information ? C'est-à-dire que s'il s'agissait de nœuds de commentaires vides, ce serait ok
  • Les nœuds de commentaire ne devraient pas être là du tout

Si vous parlez de la première option, je pense que cela peut être exagéré, mais il y a une chance qu'un opt-in puisse être ajouté. Si vous parlez de la deuxième option, leur suppression impliquerait une refonte importante du fonctionnement de la transclusion des directives et je doute que cela se produise bientôt.

@lgalfaso

Vous aimeriez que les nœuds de commentaires n'affichent aucune information ? C'est-à-dire que s'il s'agissait de nœuds de commentaires vides, ce serait ok

Je pourrais dire que ce serait une option.

@lgalfaso oui première option très bien. Exposez le corps du commentaire essentiel qui ne perturbera pas le comportement des directives actuelles.

Je suis venu ici à la recherche des mêmes réponses au même problème, mais pour des raisons différentes (c'était vraiment ennuyeux de déboguer les éléments DOM avec un million de commentaires).

Écouter d'autres personnes décrire la dépendance d'Angular aux commentaires, cela a du sens. Pour ajouter mes deux cents sur votre souci de cacher la logique de l'application. Angular est javascript, et comme nous le savons tous, il n'y a aucun moyen de vraiment sécuriser votre code javascript des utilisateurs qui veulent vraiment faire un pic et voir ce que vous avez sous le capot. Supprimer les commentaires, à mon avis, n'empêcherait que les visiteurs occasionnels d'avoir un aperçu de votre logique. Cela ne dissuadera pas un attaquant, et je serais très surpris qu'un attaquant considère même vos commentaires angulaires comme le moyen de trouver une éventuelle exposition ou une faiblesse dans votre code.

@cc17
"les commentaires montreront une logique de produit que je ne veux pas que les autres voient."
? Pour voir les commentaires, vous devez ouvrir les outils de développement du navigateur.
Là, TOUTE la logique de votre produit (partie frontale) est affichée ! Votre html (original et actuel), javascript, requêtes réseau...

@seavor
"c'était vraiment ennuyeux de déboguer les éléments DOM avec un million de commentaires sur le chemin"
Je me demande quelle page angulaire (avec un temps de réponse acceptable ;-) ) vous pouvez créer en générant "un million de commentaires"

+1

J'aimerais également voir une option pour supprimer les commentaires du HTML en direct. À mes yeux, c'est moche et distrayant. Contrairement à mon éditeur de texte, la console du développeur fait 1/3 de la page, et donc ces commentaires supplémentaires bug vraiment.

Y a-t-il plus de détails sur les raisons exactes pour lesquelles Angular en a besoin?

Moche et distrayant n'est pas une raison très puissante. ??
Les commentaires sont utilisés par angulaire comme marqueurs pour le contenu qui sera
inséré là. Par exemple, les éléments ngIf qui ne sont pas affichés en ont besoin.
Je ne pense donc pas qu'il y ait une chance réaliste qu'ils le soient un jour
supprimé. Angular 2 devrait théoriquement avoir le même problème mais c'est peut-être
différent là-bas.
Am 10.02.2016 19:16 schrieb "Alistair G MacDonald" < [email protected]

:

+1

J'aimerais également voir une option permettant de supprimer les commentaires du HTML en direct.
À mes yeux, c'est moche et distrayant.

Y a-t-il plus de détails sur les raisons exactes pour lesquelles Angular en a besoin?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/angular/angular.js/issues/8722#issuecomment -182509708
.

Oui, ng2 a aussi des commentaires pour les directives structurelles. (Je pense qu'ils utilisaient des éléments <script> , mais ils sont passés aux commentaires à un moment donné, car les éléments cassaient les sélecteurs CSS iirc.)

Oui, j'ai compris

@F1LT3R , les nœuds de commentaires sont là en tant que marqueurs. Ils sont nécessaires dans le cas où le contenu n'est pas affiché (par exemple, une expression ngIf évaluée à false, une ngSwitchWhen qui ne correspond pas à l'expression ngSwitch , etc.). Dans ce cas, nous avons besoin d'un espace réservé dans le DOM pour savoir où insérer les éléments réels plus tard (par exemple, lorsque l'expression ngIf évaluée à true, etc.).

J'espère qu'il y aura une option pour cela.

Laisser un commentaire comme celui-ci je pense que ce n'est pas une bonne idée
<!-- ngIf: transaction.status==9 && transaction.status!==8 -->

@codetrash , si vous avez une meilleure idée à proposer, nous sommes tout ouïe :smiley:

@codetrash pourquoi n'est-ce pas une bonne idée ?

@Narretz pour une application assez sensible comme les services bancaires, les services de paiement, etc.

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

pourrait conduire à une situation à risque.

@gkalpak peut-être en laissant un marqueur crypté, etc. En avez-vous ?

@codetrash Le balisage d'expression est basé sur votre code javascript qui est de toute façon exposé à l'agent utilisateur. L'obscurcissement de votre code Javascript peut rendre plus difficile l'obtention des informations, mais la logique de votre application peut toujours être extraite. Nous pourrions bien sûr essayer de supprimer / obscurcir l'expression, mais je pense personnellement qu'il n'y a aucun risque de sécurité ici et que c'est une faible priorité. Si quelqu'un veut essayer, vous êtes le bienvenu, même si je ne peux pas garantir qu'il sera fusionné.

Merci @gkalpak , c'est logique. Je pouvais voir pourquoi tenter de suivre les modifications du DOM dans JS pourrait être assez peu pratique pour les performances et la maintenabilité. Je suppose que si nous pouvions dire "Angular contrôle tout dans le DOM", cela pourrait être un peu plus faisable, mais Angular a tendance à être mélangé avec toutes sortes de bibliothèques tierces, donc... hein. Le « moindre de deux maux ».

@codetrash
<pourrait conduire à une situation à risque>>
?? Ce code n'est rien de plus que vous pouvez lire dans le html envoyé en clair au premier stade de toute façon, donc ...

+1.

@smurugavel S'il vous plaît, ne vous contentez pas de +1 pour ce problème. Il n'y a toujours aucun argument convaincant contre ces commentaires, donc simplement +1 ne nous fera pas mettre en œuvre cela.

@Narretz , comme l'a dit @cc17 , la logique métier était ma préoccupation, elle n'a pas besoin d'être vue par d'autres qui peuvent voir le code source via les outils de développement.
en parcourant les suggestions de ce fil, la première option de @lgalfaso était OK pour moi.
Alternativement, l'équipe angulaire peut-elle chiffrer ces commentaires qu'un humain ne peut pas lire ou ajouter un identifiant unique qu'angular peut suivre en interne ? juste mes pensées..

@smurugavel , comme déjà mentionné dans ce fil, ces commentaires ne contiennent rien qui ne soit déjà visible en texte brut dans vos modèles. Quiconque peut voir votre code source peut voir cette logique métier. Se débarrasser des commentaires ne résoudra pas votre problème.

J'espère qu'il y aura une option pour supprimer et obtenir à nouveau le filtrage.

Laisser un commentaire comme celui-ci je pense que ce n'est pas une bonne idée

Que faire d'autre si je dois appliquer un filtre et utiliser à nouveau ul li à ce moment-là, ma valeur li commentée apparaît à nouveau.

@ManishLSN , li . Juste un simple commentaire HTML.
Cela dit, je pense qu'il serait logique d'avoir des commentaires vides lorsque debug info est désactivé (le contenu des commentaires ne sert à rien d'autre que la "débogage").

WDYT @Narretz , @lgalfaso ?

Encore une fois (pour les personnes qui ont soulevé cette préoccupation), cela n'aura aucun impact sur la sécurité.

Nous avons besoin que les nœuds de commentaires soient dans le DOM ou Angular ne fonctionnera tout simplement pas.
Nous pouvons implémenter l'idée de supprimer le texte du commentaire si debugInfo est désactivé. C'est un changement assez simple. PRs n'importe qui ?

Merci !!!

@codetrash Ceci est fermé et je pense que c'est bon pour "cacher" la logique de l'inspecteur. Mais comme indiqué précédemment, votre code HTML et JS brut sont transmis au navigateur, il ne doit donc en aucun cas être considéré comme plus sécurisé. Cela pourrait probablement être beaucoup mieux protégé en utilisant angular côté serveur avec 2.0. Dans tous les cas, la seule "situation à risque" que je pouvais voir était s'ils pouvaient modifier les valeurs dans l'inspecteur et afficher ou enregistrer des données qu'ils ne devraient pas pouvoir - mais cela pourrait être arrêté en ne fournissant pas ces données au modèle dans la première place. Il devrait être considéré comme une mauvaise pratique d'envoyer des données sensibles depuis le serveur si elles doivent être cachées à l'utilisateur - en d'autres termes, les autorisations doivent être appliquées côté serveur, en particulier pour les services bancaires, les services de paiement, etc. Tout ce qui est envoyé au navigateur doit être considéré comme accessible au public.

C'est un cas d'utilisation intéressant Akuno. Je peux définir pourquoi ce serait
frustrant.

Je pense qu'en pratique vous voudriez filtrer certains éléments même dans un
scénario non angulaire. J'encadre, commente, etc.

Plus de travail à mettre en œuvre, oui, mais un pipeline plus propre et plus contrôlable
entre un format et un autre est probablement une bonne idée.
Le 25 mars 2016 à 02h55, "akunno" [email protected] a écrit :

J'espère que je comprends bien, car je suis dans un bateau similaire.

Actuellement mon dom contient beaucoup de commentaires et d'images comme ceci :

quand j'appelle innerHTML sur le parent de l'élément, je me retrouve avec quelque chose
comme ça:

ng-src="data:image/gif;base64,....">

Je ne connais pas un moyen d'extraire le HTML sans les directives angulaires.
J'essaie d'extraire le HTML rendu sans angulaire parce que je passe
ceci à un convertisseur qui crée un document de mot à partir de celui-ci. Actuellement le mot
doc contient un tas de balises d'image avec des X rouges car il essaie toujours
pour rendre l'image comme si c'était une image. Les commentaires sont aussi massivement
augmenter la taille de la chaîne.

J'ai essayé de supprimer les commentaires, mais je n'arrive toujours pas à trouver un moyen
pour extraire le HTML rendu sans que les directives angulaires ne le polluent.
Idéalement, lorsque j'appelle innerHTML, je voulais voir si la
ngIf était vrai ou rien, si ngIf retournait faux.

J'espère que je comprends bien, et que c'est un +1 pour un chemin
pour extraire en quelque sorte la sortie rendue sans commentaires/directives.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/angular/angular.js/issues/8722#issuecomment -201172995

autre cas d'utilisation : au moins sauter les nouvelles lignes par config pour css : pseudo https://css-tricks.com/almanac/selectors/e/empty/

@mashpie est tombé sur le même cas d'utilisation tout à l'heure, quelle coïncidence

Angular n'ajoute pas de nouvelles lignes autour des commentaires du marqueur. Voir http://plnkr.co/edit/z1rJZd7yU0TYZmDAynTh?p=preview

Vous pouvez le faire en utilisant.

app.config(['$compileProvider', fonction ($compileProvider) {
// désactiver les informations de débogage
$compileProvider.debugInfoEnabled(false);
}]);

@RHanmant cela ne supprime pas complètement les commentaires, il supprime simplement les noms de variables / propriétés des commentaires. Les commentaires sont nécessaires.

Je suis arrivé à ce rapport de problème en essayant d'utiliser une règle CSS comme #mydiv > div:last-child et le div qui devrait être le dernier enfant n'était pas à cause du commentaire angularjs par la suite.

Les sélecteurs CSS ignorent les commentaires, donc ce que vous décrivez ne peut pas se produire.

J'espère qu'il y aura une option pour cela.

Laisser un commentaire comme celui-ci je pense que ce n'est pas une bonne idée
<!-- ngIf: transaction.status==9 && transaction.status!==8 -->

Oui, tout le monde saura que le développeur était trop paresseux pour ajouter des constantes au lieu de valeurs codées en dur :).
Et oui, il y a un peu de divulgation (parce que c'est sur le frontend), mais si vous désinfectez soigneusement le support, personne n'exploitera cette information "fuite". Donc je pense que nous devrions nous concentrer sur cette partie.

Cette page vous a été utile?
0 / 5 - 0 notes