Impossible to edit when using a Proxy as rows props (v7.0.0-canary.33)

[tboyer42]

Since v7.0.0-canary.8, the rowGetter prop which was a nice way to feed the displayed data in a virtualized table has been replaced with the rows prop.
One way to keep the same kind of functionnality was to use a Proxy which would overload the [] operator, so preparing for a future migration that's what I used and it worked.
Unfortunately, after migrating from v7.0.0-canary.7 to v7.0.0-canary.33, it is impossible to edit any cell using a proxy, the problem being the following line :

react-data-grid/src/DataGrid.tsx

Line 871 in ad691c0

if (selectedPosition.mode === 'EDIT' && rows[selectedPosition.rowIdx] !== selectedPosition.originalRow) {

replacing with something like this is working though:

if (selectedPosition.mode === 'EDIT' && rowKeyGetter(rows[selectedPosition.rowIdx]) !== rowKeyGetter(selectedPosition.originalRow))

[nstepien]

Can you help me understand what is your use case for using a proxy?
Are you creating a row object every time DataGrid is trying to access a row?
For memoization/performance purposes we need rows to be not mutate unless they've changed.
Maybe your proxy could lazily create the row objects, but keep them stored once created, until they change. Does that make sense?

[tboyer42]

The row at index i is indeed created every time rows[i] is called.
The use case is to store the data in multiple objects (in the redux store) with the same key as index rather than in on big array because in my application I can display multiple tables with shared data and link filters in each tables (and I can have over 100k rows).
The way it worked with the rowGetter really was why I chose to use react-data-grid.

I also thought about lazily create the rows and store them until there is a change, but I was worried about the memory footprint, but I suppose if the user would scroll until the end of the table, unless the scroll is slow enough, few rows are actually accessed (an other use of the Proxy would be to call a rest API when needed in case there is to much data, like more than 1M rows, so in this case, I really don't want to store references to 10M rows for example...)

[nstepien]

That's fair.
I think you could either only store the last 1000 thousand accessed rows for example, or implement some sort of pagination/filtering outside the grid.