Column key is regenerated automatically even if key is already defined about fixed-data-table-2 HOT 19 CLOSED

I have found step to reproduce:
When we have horizontal scroll and column moves outside of the veiw and then comes back becomes recreated with lose his state. Even with prop allowCellsRecycling=true.

from fixed-data-table-2.

Hmm this does seem like it could lead to issues. We could use the columnKey prop as the key instead of a synthetic one, but that might cause other issues if folks aren't assuming columnKey needs to be unique...

Could you create a JsFiddle or Plunker which demonstrates the issue? Your description isn't explicit, but it seems you may have uncontrolled inputs in your cells. You should be aware that even with this fix, those inputs may not work as expected and may lose their state while you're scrolling.

from fixed-data-table-2.

Yes, we use uncontrolled input, and we can't use other in header cell for our goals. But when our input in header cell will out of the view and return we lose our data because filter component recreated.

Yes using columnKey it simply way for both, but cause some problem with uniquie key. But if you could provide new props for example "use columnKeyAsKey=true" and discribe it in documentation users will know that columnKey should be uniquie.

Also updating the component instead recreated may inrease performance.

I can show example close to our problem in few hour in JSFiddle

from fixed-data-table-2.

Unfortunately in JSFiddle I can reproduce issue only with scroll. My filter component not so simple . There is other problem which absent in my code but i think it is kind of the my problem. If you put something to first input and scroll to the end and return input will empty. With hidding the same behavior with all cell after hidded, each other will recreated. And playing with allowCellsRecycling true/false have not result for hiding, but yes it fix scroll.
Pretty way use it mount/unmount hidded component and and only update each after hidded but it possible only if we will have the same key always for this cell
JSFiddle

from fixed-data-table-2.

I think your columnKeyAsKey prop is a good solution for now. We can include that in a patch release and then turn that on by default and remove the prop with the next minor release. Would you like to submit a PR?

Also could you describe the issue you're seeing? I'm unable to reproduce any issues in your JSFiddle.

from fixed-data-table-2.

About JSFiddle: to the header I added input field, our to the first input some text, and scroll stable horizontal to the last columnKey, and return, after return to the first column, input will empty. It is expected behavior for current implementation but we can avoid.

And sorry, but what does mean "submit PR"?

from fixed-data-table-2.

Submit a PR means to create a Pull Request on github with the fix.

Here's the behavior I see in the fiddle. The input isn't lost. Maybe my screen resolution is too large?

from fixed-data-table-2.

Ohh. Sorry it was old JSFiddle link. It's correct JSFiddle. Changed only width. 200 px only for fast reproduce. We have a lot of column with width 130px in full screen table with scroll and have this problem.
Yes, I will create PR at monday or tuesday

from fixed-data-table-2.

Cool, the fiddle repros for me now. Thanks for the help, I look forward to the PR. Let mw know if you have any questions about the code base.

from fixed-data-table-2.

Joining this discussion late, but you would need allowCellsRecycling to be false in order to preserve the input fields scrolling left and right

FDT doesn't actually render columns; it renders rows and each cell is given a key of cell_${index}.

I think a simple patch would be to change this line to
var key = columnProps.columnKey || 'cell_' + i;

from fixed-data-table-2.

@KamranAsif do you think there's any need to worry about users using non unique columnKeys? Or do you think it's safe to just swap to columnKey in a patch version bump?

from fixed-data-table-2.

Hmm columnKey is suppose to be unique according to the API docs. We could add a check to make sure values are unique in DEV mode

from fixed-data-table-2.

Nice, then let's forgo the prop and make the change Kam suggests. If you could try it out and confirm it solves your issue, and if so, submit a PR, we'll merge in the solution. Thanks!

from fixed-data-table-2.

Thanks. Yes will check and submit a little bit later.

from fixed-data-table-2.

I created PR. If everything is OK, could you move it to 0.7.7?
Thanks

from fixed-data-table-2.

@wcjordan Hi. As I see fix was merged. Can I hope to receive fix in next minor version(0.7.8 as example) and when? Thanks, after that a will close issue.

from fixed-data-table-2.

Hello guys,
I have to reopen the issue because I closed it accidentally.Could you please create minor release as I need to fix this issue on production.
Thank you

from fixed-data-table-2.

@neospyk Hey, just released 0.7.8 with your change.
Closing this unless theres anything else

from fixed-data-table-2.

Thanks a lot

from fixed-data-table-2.