Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

generating unique uids when column object is cached #2364

Closed
MeMea66 opened this issue Dec 16, 2014 · 9 comments
Closed

generating unique uids when column object is cached #2364

MeMea66 opened this issue Dec 16, 2014 · 9 comments
Assignees
Milestone

Comments

@MeMea66
Copy link

MeMea66 commented Dec 16, 2014

This is an odd but fairly serious bug that occurs when the user swaps out the columndefs array entirely but there are elements in this new array that share the same attribute as the previous columndefs array -- see this plunkr: http://plnkr.co/edit/LUFGq2Ri35xlewpPXqYW?p=preview

simply click swap, and watch the table disintegrate

In the above, the two schemes that the user swaps between both share the 'name' column. Due to the fact that the default uses 'track by col.colDef.name' the column isnt recompiled and subsequently the class isnt refreshed to reflect the new uid given to the column. What is refreshed to reflect the uid is the customStyles used to compile the inline css.

@PaulL1 PaulL1 added this to the 3.0 milestone Dec 16, 2014
@c0bra
Copy link
Contributor

c0bra commented Dec 19, 2014

I see. If you supply the name property rather than the field property it works as expected. Is that an option?

@MeMea66
Copy link
Author

MeMea66 commented Dec 20, 2014

oh, thats interesting, thats certainly a better workaround than I am using (I just removed the track by).

The col class stays the same as well, meaning that setting the field col causes a new uid generation (presumably due to some cache lookup somewhere?) whereas name doesn't?

@PaulL1
Copy link
Contributor

PaulL1 commented Jan 16, 2015

@c0bra: would this be related to #1948?

@c0bra
Copy link
Contributor

c0bra commented Jan 29, 2015

I've tried the plunker again and it's no longer exhibiting any bad behavior. I just fixed #1948 but the patch hasn't been released into unstable yet so the fix must have come from somewhere else!

@MeMea66 can you confirm that you haven't altered the plunker and it appears to be fixed? Thanks!

@MeMea66
Copy link
Author

MeMea66 commented Jan 29, 2015

it still seems broken to me, it works as is because it is using the name property, if you switch the name property back to field it is still broken on the latest unstable

@c0bra
Copy link
Contributor

c0bra commented Jan 29, 2015

Is it because you're using the same field name twice without giving them unique names?

@MeMea66
Copy link
Author

MeMea66 commented Jan 29, 2015

right, The issue I think is that the ngrepeat tracks by the name field so the same column object is used, but a unique uid is generated for the column. This creates a mismatch in the css where the column object expects a css class for the old uid but it no longer exists

@c0bra
Copy link
Contributor

c0bra commented Jan 30, 2015

So what should we do if you supply { field: 'name' }, { field: 'name' }? Use an incrementing naming system like 'Name', 'Name2' for uniqueness?

@c0bra c0bra closed this as completed in 82a7213 Jan 30, 2015
@c0bra
Copy link
Contributor

c0bra commented Jan 30, 2015

That's what I went ahead and did.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants