When supporting the need for double check, a carriage return is required in a single text cell and onCellsChanged is triggered, changes become an array of one element, but a two-element array

[David]

Describe the bug

When supporting the need for double check, a carriage return is required in a single text cell and onCellsChanged is triggered, changes become an array of one element, but a two-element array

Current behavior
A clear and concise description of what you current see.

Expected behavior

changes become an array of one element

Screenshots or gifs

Your environment details

• Device: [e.g.desktop]
• OS: [e.g. iOS]
• Browser [e.g. chrome]

[David]

focusLocation and CellEditorRenderer are different components for handling table focus and editing functions. If you call tryAppendChange twice in these two places, it's probably because you're trying to update the cell's value twice, which is probably not necessary in most cases.

In ReactGrid, tryAppendChange is commonly used to apply changes to cell values. This method attempts to add the change to the ReactGrid's change set, and if the change is successful, the onCellsChanged event is triggered, allowing you to process the change and update your data.

If you call tryAppendChange in focusLocation and CellEditorRenderer, the following behavior may result:

• focusLocation calls tryAppendChange - When the focus moves to a cell, you might try to update the value of the cell.
• CellEditorRenderer calls tryAppendChange - When the editor renders and the user changes the value, you might try to apply those changes.

Under normal circumstances, a change in focus triggered by you pressing Enter should not trigger a change in value.

const isMoveRightEnable = state.props? .moveRightOnEnter
? {... moveFocusRight(state, event.keyCode), currentlyEditedCell: undefined }
: {... moveFocusDown(state), currentlyEditedCell: undefined };

tryAppendChange should only be called once when the user finishes editing, that is, in the CellEditorRenderer.

{cellTemplate.render(currentlyEditedCell, true, (cell: Compatible<Cell>, commit: boolean) => {
state.currentlyEditedCell = commit ?  undefined : cell;
// console.log(state.queuedCellChanges, 'state.currentlyEditedCell')
if (commit) state.update(s => tryAppendChange(s, location, cell));
})}

[Dawid Michota]

I don't think I understand... Could you explain this in other words so that it is easier to understand and summarize what you expect?

[David]

May I ask whether the description of the problem is not clear or the solution is not clear

[Dawid Michota]

To be honest, i don't really see the issue here.
If i understand correctly, You mean that the issue is the fact that if user pressed Enter, yet there were no changes in cell, the "changes" are saved by tryAppendChange, even if there were no changes at all. Am I right?

[Dawid Michota]

Okay, now i realized that if you click Enter after editing the cell, the handleChanges in TestGrid.tsx will recive data as changes argument the same cell twice (as two separate objects). But it won't be the case if you will just un-focus (blur) the cell with mouse.
I still can't find any bug there. So what's wrong?

[David]

Okay, now i realized that if you click Enter after editing the cell, the handleChanges in TestGrid.tsx will recive data as changes argument the same cell twice (as two separate objects). But it won't be the case if you will just un-focus (blur) the cell with mouse. I still can't find any bug there. So what's wrong?

Yes, that's the problem. Whether it's enter after editing a cell or unfocusing a cell with the mouse, what's correct is that handleChanges in TestGrid.tsx receives data to the same cell once as a changes parameter.

[Dawid Michota]

For this moment i can't really see the issue here. Im trying to understand what is the problem, but tryAppendChange, as it name says, tries to append changes, but if there are no changes, it will leave cell as it is.

[Dawid Michota]

We (react-grid "team") talked for a while about the way you resolved this problem. We decided that there are not so many contraindications to your code, and the other ways around this problem are not backward compatible. For this reason, we decided to merge #292.
Keep in mind that this fix is not really permanent solution, as it may turn out to be invalid and cause bugs, and may be changed in the future. Once again: for this moment is sufficiently good.