Bower was used to install multiple versions of jQuery which is now handled
using Yarn aliases. The remaining two packages, closure-compiler and
ng-closure-compiler were installed from zip files which is not supported by Yarn
(see https://github.com/yarnpkg/yarn/issues/1483); the first of them exists
on npm as the google-closure-compiler but only versions newer than we used are
published and they don't work with ng-closure-compiler so - instead - both were
checked in to the repository.
Fixes#16268Fixes#14961
Ref yarnpkg/yarn#1483
The quotes rule had to be disabled for e2e tests generated from ngdoc
because dgeni templates use double quotes as string delimiters.
Since we can't have guarantees that dgeni template wrappers will follow
the same JS code style the Angular 1 repo uses, we should find a way
to enforce our ESLint setup only for the parts in this repo, perhaps
via prepending a generated `/* eslint-enable OUR_RULES */` pragma.
Closes#15011
There was a ~5% improvement in the added `parsed-expressions-bp/assignment` benchmark (which only
contains assignment expressions). In real-world applications, the time spent in assignment
expressions will be a tiny fragment of the overall processing time, though.
Closes#14957
When the functions `cssClassDirectivesEnabled()` / `commentDirectivesEnabled()` on the `$compileProvider` are called with `false`, then the compiler won't look for directives on css classes / comment elements.
This can result in a compilation speed-up of around 10%.
PR (#14850)
Add a property $$watchersCount to scope that keeps the number of
watchers in the scope plus all the child scopes. Use this property
when traversing scopes looking for watches
Closes: #5799
With this change, expressions like "firstName + ' ' + lastName | uppercase"
will be analyzed and only the inputs for the expression will be watched
(in this case "firstName" and "lastName"). Only when at least one of the inputs
change, the expression will be evaluated.
This change speeds up simple expressions like `firstName | noop` by ~15%
and more complex expressions like `startDate | date` by ~2500%.
BREAKING CHANGE: all filters are assumed to be stateless functions
Previously it was a good practice to make all filters stateless, but now
it's a requirement in order for the model change-observation to pick up
all changes.
If an existing filter is statefull, it can be flagged as such but keep in
mind that this will result in a significant performance-penalty (or rather
lost opportunity to benefit from a major perf improvement) that will
affect the $digest duration.
To flag a filter as stateful do the following:
myApp.filter('myFilter', function() {
function myFilter(input) { ... };
myFilter.$stateful = true;
return myFilter;
});
Closes#9006Closes#9082
Michał Gołębiowski-Owczarek
Georgios Kalpakas
David Rodenas Pico
Martin Staffa
David Rodenas
Peter Bacon Darwin
Martin Staffa
Jason Bedard
Lucas Galfaso
Chirayu Krishnappa
Siddhartha
Leonardo Zizzamia
Igor Minar
Jeff Cross
Tobias Bosch