Angular.js: como posso remover os comentários criados por ng-if e ng-repeat?

Não posso dizer como funciona internamente, mas o angular precisa desses comentários para controlar as diretivas que podem ou não ter nós DOM reais como saída. Por exemplo, quando ngIf é falso, não há nenhum nó DOM, mas o compilador angular precisa do comentário para saber em qual posição na árvore a diretiva está localizada. Tenho certeza de que outra pessoa, por exemplo @caitp, pode explicar isso melhor.

@ cc17 por que você deseja se livrar desses elementos? Provavelmente existe uma maneira melhor de atingir seu objetivo.

os comentários mostrarão alguma lógica do produto que não quero que outras pessoas
Vejo.

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

@ cc17 https://github.com/cc17 por que você deseja se livrar deles
elementos? Provavelmente existe uma maneira melhor de atingir seu objetivo.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/angular/angular.js/issues/8722#issuecomment -53349716.

Eu concordei com @ cc17. Até eu quero alcançar o mesmo.

@ cc17 Eu gostaria de entender isso. O Angular precisa que esses nós de comentário estejam presentes por motivos que estão fora deste tópico.
Agora você disse

os comentários mostrarão alguma lógica do produto que não quero que outras pessoas vejam

Você está dizendo isso

• Você gostaria que os nós de comentários não mostrassem nenhuma informação? Ou seja, se esses fossem nós de comentários vazios, não haveria problema
• Os nós de comentário não devem estar lá

Se você está falando sobre a primeira opção, acho que pode ser um exagero, mas há alguma chance de que um opt-in possa ser adicionado. Se você está falando sobre a segunda opção, removê-los envolveria uma grande refatoração em como a transclusão de diretivas funciona e eu duvido que isso aconteça em breve.

@lgalfaso

Você gostaria que os nós de comentários não mostrassem nenhuma informação? Ou seja, se esses fossem nós de comentários vazios, não haveria problema

Eu poderia dizer que isso seria uma opção.

@lgalfaso sim primeira opção bem. Exponha o corpo do comentário essencial que não quebrará o comportamento das diretivas atuais.

Eu vim aqui procurando as mesmas respostas para o mesmo problema, mas por razões diferentes (era realmente chato depurar os elementos DOM com um milhão de comentários no caminho).

Ouvir outras pessoas descreverem a dependência do Angular em relação aos comentários faz sentido. Para acrescentar meus dois centavos à sua preocupação em ocultar a lógica do aplicativo ... Angular é javascript e, como todos sabemos, não há como realmente proteger seu código javascript de usuários que realmente querem dar uma olhada e ver o que você tem nos bastidores. Remover os comentários, em minha opinião, apenas evitaria que observadores casuais vissem sua lógica. Isso não deterá um invasor, e eu ficaria muito surpreso se um invasor considerasse seus comentários angulares como o caminho para encontrar uma possível exposição ou fraqueza em seu código.

@ cc17
"os comentários mostrarão alguma lógica do produto que eu não quero que outras pessoas vejam."
? Para ver os comentários, você deve abrir as ferramentas de desenvolvimento do navegador.
Lá, TODA a sua lógica de produto (parte frontal) é mostrada! Seu html (original e atual), javascript, solicitações de rede ...

@seavor
"foi realmente irritante depurar os elementos DOM com um milhão de comentários no caminho"
Gostaria de saber qual página angular (com um tempo de resposta aceitável ;-)) você pode criar gerando "um milhão de comentários"

+1

Eu gostaria de ver uma opção para remover comentários do HTML ativo também. Aos meus olhos é feio e perturbador. Ao contrário do meu editor de texto, o console do desenvolvedor tem 1/3 da altura da página e, portanto, esses comentários extras realmente bugam.

Há mais detalhes sobre por que exatamente o Angular precisa deles?

Feio e perturbador não é um motivo muito poderoso. 😉
Os comentários são usados ​​pelo angular como marcadores de conteúdo que será
inserido lá. Por exemplo, os elementos ngIf que não são exibidos precisam disso.
Portanto, não acho que haja uma chance realista de que algum dia sejam
removido. O Angular 2 deveria teoricamente ter o mesmo problema, mas talvez seja
diferente lá.
Am 10.02.2016 19:16 schrieb "Alistair G MacDonald" < notificaçõ[email protected]

:

+1

Eu gostaria de ver uma opção de comentários removidos do HTML ativo também.
Aos meus olhos é feio e perturbador.

Há mais detalhes sobre por que exatamente o Angular precisa deles?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/angular/angular.js/issues/8722#issuecomment -182509708
.

Sim, ng2 também tem comentários para diretrizes estruturais. (Acho que eles estavam usando elementos <script> , mas mude para comentários em algum momento, porque os elementos estavam quebrando os seletores de CSS.)

Sim entendido @Narretz , a feiura pode não ser muito motivadora, mas não está claro qual foi / é a verdadeira compensação. Ele tem um desempenho melhor usando nós DOM existentes? Não consigo imaginar que faria muita diferença (talvez eu esteja errado com isso). Ou foi apenas mais fácil iterar por meio dos nós DOM em vez de criar uma matriz JavaScript?

@ F1LT3R , os nós de comentários estão lá como marcadores. Eles são necessários para o caso em que o conteúdo não é mostrado (por exemplo, uma expressão ngIf avaliada como falsa, um ngSwitchWhen não correspondido pela expressão ngSwitch atual, etc.). Nesse caso, precisamos de um espaço reservado no DOM para saber onde inserir os elementos reais posteriormente (por exemplo, quando a expressão ngIf avaliada como verdadeira etc).

Espero que haja uma opção para isso.

Deixando um comentário como este acho que não é uma boa ideia
<!-- ngIf: transaction.status==9 && transaction.status!==8 -->

@codetrash , se você tem uma ideia melhor para propor, somos todos ouvidos: smiley:

@codetrash porque não é uma boa ideia?

@Narretz para uma aplicação bastante sensível como

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

pode levar a uma situação de risco.

@gkalpak talvez deixando um marcador criptografado etc. Você tem algum?

@codetrash A marcação de expressão é baseada em seu código javascript, que é exposto ao agente do usuário de qualquer maneira. Ofuscar o código Javascript pode dificultar a obtenção das informações, mas a lógica do aplicativo ainda pode ser extraída. Claro que poderíamos tentar remover / ofuscar a expressão, mas eu pessoalmente acho que não há risco de segurança aqui e é de baixa prioridade. Se alguém quiser tentar, você é muito bem-vindo, embora não possa garantir que será mesclado.

Obrigado @gkalpak , faz sentido. Eu pude ver por que tentar rastrear as alterações do DOM em JS pode ser bastante impraticável para desempenho e capacidade de manutenção. Suponho que se pudéssemos dizer "O Angular controla todas as coisas no DOM" poderia ser um pouco mais viável, mas o Angular tende a se misturar com todos os tipos de bibliotecas de terceiros, então ... eh. O "menor dos dois males".

@codetrash
<pode levar a uma situação de risco >>
?? Este código nada mais é que você pode ler no html enviado em texto não criptografado na primeira fase, então ...

+1.

@smurugavel Por favor, não simplesmente

@Narretz , como @ cc17 disse, a lógica de negócios era minha preocupação, que não precisava ser vista por outras pessoas que podem ver o código-fonte por meio de ferramentas de desenvolvedor.
examinando as sugestões neste tópico, a primeira opção de
Alternativamente, a equipe angular pode criptografar esses comentários que um humano não pode ler ou adicionar um identificador exclusivo que o angular pode rastrear internamente? apenas meus pensamentos ..

@smurugavel , como já foi mencionado neste tópico, esses comentários não contêm nada que já não esteja visível como texto simples em seus modelos. Quem pode ver seu código-fonte pode ver essa lógica de negócios. Livrar-se dos comentários não resolverá seu problema.

Espero que haja uma opção para remover e obter novamente na filtragem.

Deixando um comentário como este acho que não é uma boa ideia

O que mais se eu tiver que aplicar o filtro e usar ul li novamente?

@ManishLSN , não tenho certeza do que você quer dizer. Não há nenhum comentário li . Apenas um comentário em HTML simples.
Dito isso, acredito que faria sentido ter comentários vazios quando debug info está desabilitado (o conteúdo dos comentários não serve a nenhum outro propósito além de "depuração").

WDYT @Narretz , @lgalfaso ?

_{Mais uma vez (para as pessoas que levantaram essa preocupação), isto não terá qualquer impacto sobre a segurança.}

Precisamos que os nós de comentários estejam no DOM ou o Angular simplesmente não funcionará.
Podemos implementar a ideia de remover o texto do comentário se debugInfo estiver desabilitado. Esta é uma mudança bastante direta. PRs alguém?

Obrigado !!!

@codetrash Está fechado e acho que é bom para "esconder" a lógica do inspetor. Mas, como declarado antes, seu HTML e JS simples são veiculados para o navegador, portanto, não deve ser considerado de forma alguma mais seguro. Isso provavelmente poderia ser protegido muito melhor usando angular do lado do servidor com 2.0. Em qualquer caso, a única "situação de risco" que eu poderia ver é se eles pudessem alterar os valores no inspetor e visualizar ou salvar dados que não deveriam ser - mas isso poderia ser interrompido por não fornecer esses dados ao modelo em o primeiro lugar. Deve ser considerado uma má prática enviar dados confidenciais do servidor se eles devem ser ocultados do usuário - em outras palavras, as permissões devem ser aplicadas do lado do servidor, especialmente para serviços bancários, de pagamento, etc. Qualquer coisa enviada ao navegador deve ser considerados publicamente disponíveis.

Esse é um caso de uso interessante, Akuno. Eu posso definir porque isso seria
frustrante.

Acho que, na prática, você gostaria de filtrar certos elementos até mesmo em um
Cenário não angular. I frames, comentários, etc.

Mais trabalho para implementar, sim, mas um duto mais limpo e mais controlável
entre um formato e outro é provavelmente uma boa ideia.
Em 25 de março de 2016 02:55, "akunno" [email protected] escreveu:

Espero estar entendendo isso corretamente, porque estou em um barco semelhante.

Atualmente, meu dom contém muitos comentários e imagens como este:

quando chamo o innerHTML no pai do elemento, acabo com algo
como isso:

ng-src = "dados: imagem / gif; base64, ....">

Não conheço uma maneira de extrair o HTML sem as diretivas angulares.
Estou tentando extrair o HTML renderizado sem angular porque estou passando
isso para um conversor que cria um documento de palavra a partir dele. Atualmente a palavra
doc contém um monte de tags de imagem com X vermelho porque ainda está tentando
para renderizar a imagem como se fosse uma imagem. Os comentários também são massivos
aumentando o tamanho da corda.

Tentei remover os comentários, mas ainda não consigo descobrir uma maneira
para extrair o HTML renderizado sem diretivas angulares poluindo-o.
Idealmente, quando chamo o innerHTML, gostaria de ver se o
ngIf era verdadeiro ou, alternativamente, nada, se ngIf retornava falso.

Espero estar entendendo isso corretamente, e que este é um +1 para uma maneira
para extrair de alguma forma a saída renderizada sem comentários / diretivas.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/angular/angular.js/issues/8722#issuecomment -201172995

outro caso de uso: pelo menos pular novas linhas por configuração para css: pseudo https://css-tricks.com/almanac/selectors/e/empty/

@mashpie encontrou o mesmo caso de uso agora, que coincidência

O Angular não adiciona novas linhas ao redor dos comentários do marcador. Consulte http://plnkr.co/edit/z1rJZd7yU0TYZmDAynTh?p=preview

Você pode fazer isso usando.

app.config (['$ compileProvider', function ($ compileProvider) {
// desativar informações de depuração
$ compileProvider.debugInfoEnabled (false);
}]);

@RHanmant isso não remove os comentários completamente, apenas remove os nomes de variáveis ​​/ propriedades dos comentários. Os comentários são necessários.

Cheguei a este relatório de problema ao tentar usar uma regra de css como #mydiv > div:last-child e o div que deveria ser o último filho não era devido ao comentário do angularjs posterior.

Os seletores CSS ignoram os comentários, então o que você descreveu não pode acontecer.

Espero que haja uma opção para isso.

Deixando um comentário como este acho que não é uma boa ideia
<!-- ngIf: transaction.status==9 && transaction.status!==8 -->

Sim, todos saberão que o dev estava com preguiça de adicionar algumas constantes em vez de valores codificados :).
E sim, há um pouco de divulgação (porque está no frontend), mas se você higienizar o backup completamente, ninguém vai explorar essa informação "vazada". Então, acho que devemos nos concentrar nessa parte.