Infinite beforeChange hook looping => setDataAtRowProp uses wrong changeSource for processChanges call


 this.setDataAtRowProp = function (row, prop, value, source) {
    const input = setDataInputToArray(row, prop, value);
    const changes = [];
    let changeSource = source;
    let i;
    let ilen;
    for (i = 0, ilen = input.length; i < ilen; i++) {
      const [visualRow, inputProp, newValue] = input[i];
      changes.push([visualRow, inputProp, dataSource.getAtCell(this.toPhysicalRow(visualRow), inputProp), newValue]);
    }

    // TODO: I don't think `prop` should be used as `changeSource` here, but removing it would be a breaking change.
    // We should remove it with the next major release.
    if (!changeSource && typeof row === 'object') {
      changeSource = prop;
    }
    const processedChanges = processChanges(changes, source);
    instance.runHooks('afterSetDataAtRowProp', processedChanges, changeSource);
    validateChanges(processedChanges, changeSource, () => {
      applyChanges(processedChanges, changeSource);
    });
  };

Good day to you. This bug is present in version 16.2

The processChanges call in setDataAtRowProp function in core.mjs file should use changeSource as parameter, not source. This can lead to infinite hook looping if you rely on the source to avoid infinite hook looping (ex. if you use setDataAtRowProp inside beforeChange hook which would return false and let the setDataAtRowProp carry on further changes).

The infinite hook looping occurs because the first thing processChanges does is firing the beforeChange hook again.

For those having the same issue, I have had success by using the following workaround :

//@ts-expect-error
hotInstance.setDataAtRowProp(myChanges, 'my-source', undefined, 'my-source');

Have a good day

Sylvain.

Hi @renaud.bellotto

Thank you for reporting this. We are investigating the issue on our side, but if you could also share a code demo where the problem can be replicated it would be helpful.

Hi @renaud.bellotto

I tried to compare this hook in 16.1 and 16.2 but I can’t get the same result as you so I have to ask you for a minimal example where this problem can be replicated.

Hi @renaud.bellotto did you have time to test it further?