-
Notifications
You must be signed in to change notification settings - Fork 27.4k
how i can remove the comments created by ng-if and ng-repeat? #8722
Comments
I can't tell you how it works internally, but angular needs these comments to keep track of directives that may or may not have actual DOM nodes as output. For example, when ngIf is false, there's no DOM node, but the angular compiler needs the comment to know at which position in the tree the directive is located. I'm sure someone else, for example @caitp can explain this better. |
@cc17 why do you want to get rid of these elements? There's likely a better way to achieve your goal. |
the comments will show some product logic that i don't want other people 2014-08-26 7:05 GMT+08:00 Brian Ford [email protected]:
|
I agreed with @cc17. Even I want to achieve the same. |
@cc17 I would like to understand this. Angular needs these comment nodes to be present for reasons that are outside of this topic.
Are you saying that
If you are talking about the first option, then I think it might be a stretch but there is some chance that an opt-in can be added. If you are talking about the second option, then removing them would involve a big refactor on how directives transclusion works and I doubt that will happen soon. |
I could say that would be an option. |
@lgalfaso yes first option fine. Expose essential comment body that will not break present directives behavior. |
I came here looking for the same answers to the same problem, but for different reasons (it was just really annoying debugging the DOM elements with a million comments in the way). Listening to other people describe Angular's dependency on the comments, it makes sense. To add my two cents on your concern of hiding app logic.. Angular is javascript, and as we all know, there's no way to really secure your javascript code from users who really want to peak in and see what you got under the hood. Removing the comments, in my opinion, would only keep casual peekers from getting a look at your logic. It won't deter an attacker, and i'd be highly surprised if an attacker would even consider your angular comments as the route to finding a possible exposure or weakness in your code. |
@cc17 |
@seavor |
+1 I would like to see an option to remove comments from the live HTML too. To my eyes it is ugly and distracting. Unlike my text editor the developer console is 1/3 of the page high, and so these extra comments really bug. Are there more details on why exactly Angular needs these? |
Ugly and distracting is not a very powerful reason. 😉
|
Yes, ng2 has comments for structural directives too. (I think they were using |
Yes understood @Narretz, ugliness may not be hugely motivating, but it's unclear what the actual tradeoff was/is. Does it perform better by using existing DOM nodes? I can't image that would make much of a difference (maybe I'm way off with that). Or was it just easier to iterate through the DOM nodes rather than create a JavaScript array? |
@F1LT3R, the comment nodes are there as markers. They are necessary for the case when the contents are not shown (e.g. an |
I hope there will be an Option for that. Leaving comment like this I think its not a good idea |
@codetrash, if you have a better idea to propose, we're all ears 😃 |
@codetrash why is it not a good idea? |
@codetrash The expression markup is based on your javascript code which is exposed the user agent anyway. Obfuscating your Javascript code may make it more difficult to get the information, but your application logic can still be extracted. We could of course try to remove / obfuscate the expression, but I personally think there's no security risk here and it's low priority. If someone wants to give it a shot, you are very welcome, although I can't guarantee that it will be merged. |
Thanks @gkalpak, makes sense. I could see why attempting to track the DOM changes in JS might be quite impractical for performance and maintainability. I suppose if we could say "Angular controls all things in the DOM" it might be somewhat more feasible, but Angular tends to get mushed together with all kinds of 3rd-party libraries so... eh. The "lesser of two evils". |
@codetrash |
+1. |
@smurugavel Please don't simply +1 this issue. There's still no compelling case against these comments, so simply +1 will not make us implement this. |
@Narretz , like @cc17 said, business logic was my concern, that need not be seen by others who can see the source code through developer tools. |
@smurugavel, as already mentioned in this thread, these comments do not contain anything that is not already visible as plain text in your templates. Whoever can see your source code can see this business logic. Getting rid of the comments won't solve your problem. |
I hope there will be an Option for remove and get this again on filteration. Leaving comment like this I think its not a good idea What else if i have to apply filter and use ul li again at this time my commented li value gets appear in view again. |
@ManishLSN, not sure what you mean. There is no commented Again (for people that raised this concern), this will have no impact on security. |
We need comments nodes to be in the DOM or Angular simply will not work. |
…bled is false When debugInfoEnabled is `false` when comments generated by transclusions, ngIf, ngRepeat and ngSwitch will not contain any information about the directive nor the expression associated with it. Closes: angular#8722
…bled is false When debugInfoEnabled is `false` when comments generated by transclusions, ngIf, ngRepeat and ngSwitch will not contain any information about the directive nor the expression associated with it. Closes: angular#8722
…bled is false When debugInfoEnabled is `false` when comments generated by transclusions, ngIf, ngRepeat and ngSwitch will not contain any information about the directive nor the expression associated with it. Closes: angular#8722
…bled is false When debugInfoEnabled is `false` when comments generated by transclusions, ngIf, ngRepeat and ngSwitch will not contain any information about the directive nor the expression associated with it. Closes: angular#8722
…bled is false When debugInfoEnabled is `false` when comments generated by transclusions, ngIf, ngRepeat and ngSwitch will not contain any information about the directive nor the expression associated with it. Closes: #8722
Thanks !!! |
@codetrash This is closed and I think it's good for "hiding" the logic from the inspector. But as stated before, your plain HTML and JS are served to the browser, so it shouldn't be considered in any way to be more secure. This could likely be protected much better by using server-side angular with 2.0. In any case, the only "risky situation" I could see is if they could change values in the inspector and either view or save data they shouldn't be able to - but this could be stopped by not providing that data to the model in the first place. It should be considered bad practice to send sensitive data from the server if it should be hidden from the user - in other words, permissions should be enforced server-side, especially for banking, payment service, etc. Anything sent to the browser should be considered publicly available. |
That's an interesting use case Akuno. I can set why that would be I think in practice you would want to filter out certain elements even in a More work to implement, yes, but a cleaner more controllable pipeline
|
another use case: at least skipping newlines by config for css:empty pseudo to get working https://css-tricks.com/almanac/selectors/e/empty/ |
@mashpie came across the same use case just now, what a coincidence |
Angular does not add newlines around the marker comments. See http://plnkr.co/edit/z1rJZd7yU0TYZmDAynTh?p=preview |
You can do that by using. app.config(['$compileProvider', function ($compileProvider) { |
@RHanmant this doesn't remove the comments completely, it just removes variable / property names from the comments. The comments are necessary. |
I came to this issue report when trying to use a css rule like |
CSS selectors ignore comments, so what you described cannot happen. |
Yes, everyone will know the dev was too lazy to add some constants instead of hardcoding values :). |
I have a scenario where I check the content of an element in order to do things, but it treats the comments as being the actual content, so the app breaks because of it. So now I will probably have to force other developers to manually set a boolean to say if the element has content or not, instead of just being able to check it directly. Or remove the comments before checking the content. Either option is annoying. |
@skog-newglue but if you are checking for content, why not check for node type, too? Anyway, you shouldn't be using angular.js anymore. It's totally unsupported. |
@Narretz Ah didn't realise this was posted in AngularJS, it's still an issue in the latest Angular though, which I'm using. Not sure if I can do that since I'm getting the content with innerHTML, which gives you a string. |
Is there a way to prevent Angular from creating "helper" HTML comments? For example,
<div ng-include="myTemplate"></div>
Will transform into something like
How do I stop this?
The text was updated successfully, but these errors were encountered: