How to implement autosave feature covering any possible type of change?

I’m currently evaluating this tool, and so far it looks quite promissing. But reading the question below, I realize that not all changes to the table data triggers the afterChange hook.

https://forum.handsontable.com/t/on-drag-afterchange-hook-is-not-working/5505/6

So, the “autosave” feature in the demo here:

…only works with that simple use case. But if one has activated “advanced” features, like being able to autofill cells, move/delete rows/colums etc, then the afterChange hook isn’t enough.

Is it documented somewhere how one can implement a fool proof autosave feature, that covers every possible type of change to the data?

Hi @jimi.hullegard

while setting up a connection between the table and any external logic (database, visualizations), basics are

  1. getData() method - It returns the array of arrays as a dataset with all the updates many by user
  2. getSourceData() method - it returns the array of objects (if data is an object) with all the updates many by the user
  3. getDataAtCell() if you want to track down a single cell value
  4. beforeChange / afterChange - callbacks that are fired for every change in a cell’s value.

If you allow adding and removing of columns are rows, you should also check

  1. alter() method - this a method to alter the number of columns and rows
  2. afterRemoveCol / afterCreateCol - callbacks that run after altering the number of columns
  3. afterRemoveRow / afterCreateRow - callbacks that run after altering the number of rows

If you allow changing the orders of columns and rows

  1. afterRowMove - callback fired after a row changes its position
  2. afterColumnMove - callback fired after a column changes its position

The beforeChange and afterChange hooks are for data CRUD operations only. If you allow the use of plugins, you may also want to use plugin hooks, like afterColumnSort.

Hi Aleksandra,

Is there a reason why a delete of a row/column, or a move of a row/column, the afterChange isn’t triggered? I would say that all those things changes cell values.

And, if I understood you correctly, there is no single unified way to handle any possible change in data, regardless of configuration (including plugins)? This feels like a big shortcoming, if you ask me. Because even if I manage to write code that covers all possible events given our current setup, if that setup changes in the future (allowing more features, or adding some third party plugin), we might miss an event that actually alters the data, and thus potentially loose data as a result.

You really should have some kind of catch all “dataChanged” event/hook. That way, we don’t have to think about how the data was changed, just that it has been changed.

I’m so sorry for the delay @jimi.hullegard I did not get the notification upon your update :frowning:

Generally, the row/column removal does not change a cell - it changes the dataset, but the value of the cell internally registered at physical index 0, 0 is still the same. And yes, that is correct - there’s not a universal hook that’s triggered to all those changes. I mean, there’s afterRender() (per table) and afterRenderer() (per cell) that are called each time table needs to rerender, that is

  • cell value change
  • row/column removal, addition
  • cell meta changes (for example a cell changes it;s background color)
  • all UI changes for plugins, like: sorting, filtering, row/column resize/fixing/moving, etc.

But depending on your logic on afterRender() might be too heavy, and I generally do not recommend it.