DataTable: stale edit state on new values set

[howkymike]

Describe the bug

When using a single DataTable component to render multiple datasets, the editing state is not cleared upon switching datasets. This results in unexpected behavior when editing cells, as described below:

• Scenario: If a cell with id=1 from the first dataset has a value of "foo" and is in edit mode, switching to a second dataset and opening the editor for a cell with the same id=1 (but with a value of "bar") results in a blank value ("") being displayed in the editor.
• Worse Scenario: If both datasets have fields with the same names, the value displayed and persisted in the editor may incorrectly come from the previous dataset.

Root Cause Analysis

After debugging the PrimeReact internals, I observed the following:

1. The props.editingKey is set as the row's id.
2. The props.editingMeta object stores the editing state for rows in the table. However:

• editingMeta is not cleared when switching datasets.
• It behaves like a cache. Once data for a row's id is saved in editingMeta, it is not updated or refreshed when datasets are switched.
• In the onEditingMetaChange function, if editingMeta[editingKey] is undefined, it sets the correct row data. However, if it is already defined, the cached (and potentially outdated) value persists from the previous dataset.

This mechanism leads to stale or incorrect values being displayed when switching datasets.

Problematic file: DataTable.js

Reproducer

You can reproduce the issue by using this demo:

https://stackblitz.com/edit/github-dbvsrcmp?file=src%2Fmain.tsx,src%2FGeneric.jsx,src%2Fservice%2FThirdService.jsx,src%2Fservice%2FSecondService.jsx,src%2FApp.tsx

Here’s an additional visualization of the behavior:

Screen.Recording.2025-06-27.at.11.06.37.mov

System Information

primereact: latest => 10.9.6 
react: 18.2.0 => 18.2.0

Steps to reproduce the behavior

1. Open the editor for a cell with id=1 in the first dataset.
2. Without closing the editor, switch to the second dataset.
3. Open the editor for a cell with id=1 in the new dataset.
4. Notice that the editor shows the value from the previous dataset instead of the correct value for the current dataset.

Expected behavior

When opening a cell editor, the value displayed should always come from the active dataset, reflecting its current state. Any residual or outdated values from previously edited datasets should be cleared.

Solution Proposal

The root cause of this issue appears to stem from allowing multiple cell editors to be opened simultaneously. A possible solution would be to restrict editing to only one cell at a time. This would eliminate conflicts and ensure that the editing state remains consistent with the active dataset.

[howkymike]

This may be fixed by adding

key={"mydatatable-" + variant}

to the DataTable component to force component state reset

But do we really want multiple cell editors in the memory? It complicates a logic, adds additional rerenders and because of it sometimes there is a bug that we can have multiple cell editors opened.

[melloware]

@acc-cassio @kl-nevermore thoughts?

[jasonporath]

I'll add, this has been biting my team pretty hard, but we have encountered it in a different way. I don't have time to do a repro case, but basically:

• Create a DataTable with 3 columns: A, B, and C, editMode "cell".
• When a row is edited, have a function run check to see if its fields A and B have been filled.
• If so, based on their values, modify field C.
• At that point, Field C displays properly in view mode -- but if you just tab between the fields, going from one editor to the next, the new value does not show up in the editor. It will not show up until you click on another row and back onto field C.

This is because the editing values are stashed away on a per-row basis (even when the editing mode is cell), and there are no methods of directly modifying the internal editing state aside from editorCallback, and that only affects the directly-affected column in question.

(as for the "why" of the workflow we've outlined -- our datatable represents tasks the users are authoring, and based on fields A and B, we're trying to auto-determine a baseline "difficulty" -- field C -- but give the users the ability to override it)

[jasonporath]

Here is some code that seems to fix it for our use case. I am a relative JS neophyte and don't have a good sense of the rest of the codebase, so please alter if you think this is unworkable code.

It's meant to be inserted into BodyCell.js starting at line 30 (after the const { ptm, ptmo, cx } = props.ptCallbacks; line).

    const lastRowState = React.useRef(null);

    /**
     * Sync the internal editing state to any incoming programmatic changes to the row values.
     */
    React.useEffect(() => {
        let deltaExists = false;

        if (!lastRowState.current) {
            deltaExists = true;
        } else if (lastRowState.current[props.field] !== props.rowData[props.field]) {
            deltaExists = true;
        }

        if (!deltaExists) {
            return;
        }

        const curState = editingRowDataStateRef.current || props.rowData;
        const newState = { ...curState };

        ObjectUtils.mutateFieldData(newState, props.field, props.rowData[props.field]);
        setEditingRowDataState(newState);
        editingRowDataStateRef.current = newState;

        lastRowState.current = props.rowData;
    }, [props.rowData, props.field]);

Apologies for this not being a PR, my employer has some very antiquated ideas about us officially contributing to open source projects.

[howkymike]

@jasonporath Thanks for the suggestion! I was actually thinking of going in the opposite direction by simplifying and removing logic rather than adding new functionality, in order to improve performance.

I would definitely take a closer look at BodyCell.js and DataTable.js.

Regarding multiple cell editors opened at once, we have here two problems - one about rendering multiple cell editors, second about not closing multiple cell editors. Maybe we could solve it by changing onEditingMetaChange function to something like this:

const onEditingMetaChange = (e) => {
    const { rowData, field, editingKey, editing } = e;
    // START MY LOGIC
    if (props.editMode === 'cell') {
        setEditingMetaState(editing ? { [editingKey]: { data: { ...rowData }, fields: [field] } } : {});
        return;
    }
   // STOP MY LOGIC
   // BELOW FUNCTION WITHOUT ANY CHANGES
    ....
};

I am also thinking how #7951 will impact our cases.

[gnawjaren]

We encountered similar issues, and #7951 did not resolve them in our case.

However, applying the following diff appears to fix the problem for us:

diff --git a/components/lib/datatable/BodyCell.js b/components/lib/datatable/BodyCell.js
index 14f89e2e2..39dac894c 100644
--- a/components/lib/datatable/BodyCell.js
+++ b/components/lib/datatable/BodyCell.js
@@ -112,11 +112,8 @@ export const Cell = (props) => {
             onBeforeCellEditHide(params);
         }

-        /* When using the 'tab' key, the focus event of the next cell is not called in IE. */
-        setTimeout(() => {
-            setEditingState(false);
-            unbindDocumentClickListener();
-        }, 1);
+        setEditingState(false);
+        unbindDocumentClickListener();
     };

     const switchCellToViewMode = (event, submit) => {

It’s not entirely clear if this change is safe in all cases, but the reasoning seems valid: the setTimeout causes the cell to remain in editing mode after the next cell has already received focus. This might have made sense back when IE was still relevant, but it’s questionable if that delay is still necessary today.