search

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.
https://hjalmers.github.io/angular-generic-table/
MIT License
105 stars 55 forks source link

Rendering table changes the original object #263

Closed harryy2510 closed 5 years ago

harryy2510 commented 6 years ago

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?

hjalmers commented 6 years ago

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.

harryy2510 commented 6 years ago

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?

hjalmers commented 6 years ago

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:)

harryy2510 commented 5 years ago

Sure! let me give it a try.

harryy2510 commented 5 years ago

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.

hjalmers commented 5 years ago

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.