-
Notifications
You must be signed in to change notification settings - Fork 27.4k
Optimization: "pure" filters #697
Comments
We discussed this with Vojta and both of us agree that this would be a great feature to have. It requires some significant changes to $parse, $watch and filter api, but it's doable. In the mean time caching/memoizing filters is the best workaround. |
I had an issue where a coworker was filtering out html before it's insertion into a textarea for use in a wysiwyg. However every time the user edits in the wysiwyg and the textarea is updated, the refresh would cause the filter to re-fire and screw up the wysiwyg. This is like, every couple of key presses, and WYSIWYGs don't need filtering (usually) as they handle it themselves. If you're still with me, I told him that we should be filtering the data when it's retrieved (in the model/service layer), as the business logic should be responsible for validating/sanitizing/normalizing it before it is spread out and used across the app. This is my general design approach. Perhaps look towards relocating your logic to when the data is retrieved? |
Another report of the same: #1149 |
As part of our effort to clean out old issues, this issue is being automatically closed since it has been inactivite for over two months. Please try the newest versions of Angular ( Thanks! |
Currently (as of 10.6), filters in expressions in a template are called on every $watch iteration.
It would speed things up if we could declare a filter as pure (ie, for a given input the same output will always be produced) so that these calls could be removed from the $watch (just watch the input instead).
The text was updated successfully, but these errors were encountered: