Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
65
Grid State Persistence not working with RowIslands when called from ngOnDestroy
posted

This is a follow up from my last post 'Grid state on hierarchical grid' see link:

https://www.infragistics.com/community/forums/f/ignite-ui-for-angular/124279/grid-state-on-hierarchical-grid

So after a long few days i have found the problem.

It turns out that the parentRowId is being cleared before the component is destroyed.

I followed the Hierarchical Grid State persistence example here:

https://www.infragistics.com/products/ignite-ui-angular/angular/components/hierarchicalgrid/state-persistence#demo

and found that this works as expected. I noticed that the saveGridState is called from a subscribed callback from router in ngOnInIt, we have been using ngOnDestroy because this seemed like a logical place and it has been working perfectly well for the last few years for us on the basic igx-grid.

However since trying to apply the same logic to IgxHierarchicalGridComponent the rowIslands child grids get destroyed somewhere before ngOnDestroy,

So if you trace through the code in igniteui-angular.js and method getParentRowId this.childGrids has a zero length array:

Therefore the resulting gridState rowIslands have undefined parentRowID

So when you return back to the component and re-apply the gridState on ngAfterViewInit the rowIslands are ignored.

My questions are: Is this a bug? And is the only way for this to work is to use the router callback in ngOnInIt

Thanks.

  • 2480
    Offline posted

    Hello Chris,

    Thank you for posting to Infragistics Community!

    I was able to reproduce this behavior when saving the grid state in the onDestroy hook. I am currently investigating whether this might be an issue with the grid state directive, or it is rather caused by Angular’s lifecycle and possibly the order of destroying parent/child components.

    In case of the latter, I suppose it would be best to stick with the router callback approach from the demos. In general, it is the recommended approach, as the on destroy hook will not be fired on page refresh or possibly other navigation events.

    I will let you know as soon as I have more information on the matter.

    Best regards,
    Bozhidara Pachilova
    Associate Software Developer