restoreState triggering multiple filterChanged events

[tbaeg]

When restoring a particular grid state with several filter parameters I noticed the filterChanged event triggered several times invoking the listener several times (in my case a bunch of ajax requests).

Base on the documentation (and code), the event doesn't return which filter changed so it seems useless to trigger all those events especially in the context of restoring state. Is this by design? If not, this seems like a bug to me. It would be better if it watched for changes similar to sortChanged.

I don't have a plunkr, but a simple way to reproduce would be to have multiple filters applied to a grid, save the state, restore the state. The grid.api.core.on.filterChanged should trigger several times when restoring the grid state.

Where the filterChanged event is invoked: https://github.com/angular-ui/ui-grid/blob/master/src/features/saveState/js/saveState.js#L592.

Where the sortChanged event is invoked: https://github.com/angular-ui/ui-grid/blob/master/src/features/saveState/js/saveState.js#L610

[tbaeg]

Any traction on this? Happy to make the needed changes and submit a PR if deemed a bug.

[heppa]

I have the same issue...

What I did:

• set a scope variable isRestoring to true before calling vm.gridApi.saveState.restore($scope, data);
• now, to the ugly part: $timeout($scope.isRestoring=false, 2000); ==> I am assuming, that the restore is done within 2secs, and that the user does not start to change values within 2 secs. Of course, you could prevent this by making it modal or something.
• In my event processor functions, I'm checking, whether we are in restore mode and stop further processing.

I would see three ways to overcome this in the ui-grid code:

1. Raise a dedicated event, when the restore is finished. Then you could have a variable that you set to true, before starting to restore and set it back to false when the "restore_finished" event was triggered.

2. Raise different events from the restore actions. Instead of "filter_changed", trigger "filter_restored". But this would of course break the API and maybe some people are expecting the events to be triggered when restoring.

3. Add a boolean parameter to the restore call, whether or not to raise events. ==> this would be my preferred option.

[mbliesath]

Same issue here. I save grid state to localStorage and this was causing hidden columns to suddenly become visible and saved in the state. My resolution was to use

$scope.$on("$destroy", function() {
   //save state here
});

I have a grid directive that is reused through my application. It makes sense as the user navigates through the app to save state when the grid controller is destroyed. The problem is that if changes are made and the browser is refreshed, the changes are not saved. Having a manual "Save" button isn't an option per project management, so I think I'll have to live with this.

[1ambda]

I also just used isRestoring flag to avoid initial event triggering. But failed for gridApi.pagination.on.paginationChanged in 4.0.4

[vinhboy]

Bump. I also think we should consider this a bug. It really doesn't play nice with useExternalFiltering. For me, I use underscore's _.debounce() to limit the amount of AJAX request fired from the filterChanged callbacks.