hjalmers / angular-generic-table

A generic table for Angular 2+. Generic table uses standard markup for tables ie. table, tr and td elements etc. and has support for expanding rows, global search, filters, sorting, pagination, export to CSV, column clicks, custom column rendering, custom export values.

Home Page:https://hjalmers.github.io/angular-generic-table/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Rendering table changes the original object

harryy2510 opened this issue · comments

I am using generic table with @ngrx/store. Data subscribed from store when passed to config object is changed mutated with $$gtRowId and since the referenced directly from store, changes can be observed in store too. If I add an extra key to the config object, that is too mutated upto the store.

Can we make a copy of the data before mutating it?

This has been on my to-do list for some time now and ngrx is definitely something generic table should support. I'm not fond of the way the table is manipulating the data now and there's a plan to change it but it also means rewriting a lot from scratch. Angular has also evolved over the years so there are a lot of things that could be simplified and improved if the table would be rebuilt from scratch.

I'm afraid it's not as simple as just coping the data before manipulating but I've created a milestone and added this issue to it. We have a project at work that needs this too so I hope I'll get some help implementing full support for ngrx.

To know the issue further, Can you please tell me what all things will get affected if we try to create a deep copy of the data provided in the table?
As while providing data to the table, I myself create a deep copy of data. So how would the behavior of the table will get affected if the copy is made as soon as data is provided to the table?

Well it's currently not built using the concept of immutable objects and some of the features rely on objects being modified by pipes. Making a deep copy initially when data is added/changed would probably work but it wouldn't really solve the problem in my opinion. I'd rather re-write the pipes and stick to an immutable pattern. It's been a while since I worked with the code but I'm pretty sure it would qualify as a breaking change too. But like I said this is something we want to do and you're more than welcome to try it out and create a pull request. One way without introducing breaking changes would be to add it as an option to begin with:)

Sure! let me give it a try.

The code needs a lot of change if moving to an immutable pattern. I've updated the initial cloning of data for now. Will try making changes to pipes too.

Thanks for contributing @harryy2510, the option for deep copying the initial data before manipulating the objects is now available with the release of v4.17.0 and I've added the option to the wiki as well.