Debounce of the digests triggered by store modification

[jtassin]

capability for ngRedux to debounce the digests

The problem

In my huge app, I have a lot of stimulations that modify the store and each one lead to a digest (via $rootScope.$evalAsync). The accumulation of digests considerably affect the performance of the application.

Solution

We added a use of lodash.debounce in the digest middleware to avoid digesting too much.

Content of the PR

• add lodash.debounce to the dependencies
• Use of lodash.debounce in the digest middleware
• Creation of a config for ngRedux
• Documentation of the config
• unit test for the debounce
• Correction of a problem with redux-thunk in ngRedux.js

Use of the fonctionnality in my app

import angular from 'angular';

angular.module('ngapplication').config(($ngReduxProvider) => {
  'ngInject';

  // eslint-disable-next-line
  $ngReduxProvider.config.debounce = {
    wait: 250,
    maxWait: 500,
  };
});

last but not least

Thx for your usefull lib ;-)

[AntJanus]

if we do a default debounce of 1ms, would it be possible for us to batch updates "per tick" essentially? I'm thinking of how you might queue several actions at the same time and instead of digesting each one immediately, we'd let it all run on the next tick/frame/whatever.

I'm not sure if $evalAsync does this already or not.

[jtassin]

The "per tick" should be already covered by the $evalAsync.

I think that 1ms won't make a real performance gain.

Here we set it to {wait: 100, maxWait: 500} for a gain of ~50% of digests.

[AntJanus]

@jtassin this is fantastic functionality! I'd like to add this ASAP. Can you look over it once more? I definitely let this one linger for way too long.

[bjohnso5]

Looks like there's a typo here, I assume this is intended to be maxWait

[jtassin]

You're right, thx for review.
It's corrected.