Make angular.$apply optional

[miguelangelmunoz]

In order to avoid calling scope.$apply(scope.infiniteScroll); every time, let's add the option to handle it with a parameter.

[graingert]

@miguelangelmunoz ngInfiniteScroll doesn't call $rootScope.$apply

[miguelangelmunoz]

Sorry, scope.$apply(scope.infiniteScroll);

[graingert]

@miguelangelmunoz it already checks to see if we're in a phase: https://github.com/sroze/ngInfiniteScroll/blob/master/src/infinite-scroll.js#L89-L93

[danielkocsan]

Hi @graingert,

The intention is to have an option to manage when angular digest is executed. This is for performance purposes.
In our application we use this library having tons of bindings so a digest flow can take long. Would be nice to have the possibility to execute digest wherever and whenever we want.

Miguel created a brach adding a new parameter where you can set avoiding the explicit call on $apply().

[graingert]

@danielkocsan have you considered https://material.angularjs.org/latest/api/directive/mdVirtualRepeat

[danielkocsan]

Hi @graingert,

Not yet, it looks like a thing to consider for our further improvements. Thanks for the tip and also for the quick responses.

Currently though, we use this library and we are having performance issues which should be fixed.

Do you think we can apply this change? Could be useful for other users as well and doesn't affect the rest as it defaults to the current behaviour. @miguelangelmunoz has added test coverage too.

[graingert]

@danielkocsan I've not seen anything yet...?

[miguelangelmunoz]

@graingert you can find the Pull Request in the following link:

#300

[graingert]

I don't think it's a good idea to expose this sort of interface. I think this should always call $apply().

Also IMHOP ngInfiniteScroll is in permanent feature freeze / maintenance mode and people should be using https://material.angularjs.org/latest/demo/virtualRepeat or waiting for angular/components#823

[danielkocsan]

It would make sense to explain why do you think things rather then just saying them.

[graingert]

This is because handler is responding to a callback from the dom, like $timeout and $http this must invoke $apply for angular to update the model.

[danielkocsan]

This is not the same case.
The responsibility of this library is just to call the "loadMore" function whenever the user scrolls out of the container.
All managing your items and rendering them is (should be) out of scope.

[graingert]

the loadMore function is passed as a directive callback, all directive callbacks should trigger a digest cycle, eg ngClick

[danielkocsan]

You are safe if you do that but not efficient. That's why there are multiple performance issues reported with Angular 1.x