This page covers a non-latest version of Handsontable.
# Events and hooks
# Overview
Callbacks are used to react before or after actions occur. We refer to them as hooks. Hooks share some characteristics with events and middleware, combining them both in a unique structure.
# Events
If you only react to emitted hooks and forget about all their other features, you can treat hooks as pure events. You would want to limit your scope to after
prefixed hooks, so they are emitted after something has happened and the results of the actions are already committed.
hot.addHook('afterCreateRow', (row, amount) => {
console.log(`${amount} row(s) were created, starting at index ${row}`);
})
# Middleware
Middleware is a concept known in the JavaScript world from Node.js frameworks such as Express or Koa. Middleware is a callback that can pipe to a process and allow the developer to modify it. We're no longer just reacting to an emitted event, but we can influence what's happening inside the component and modify the process.
hot.addHook('modifyColWidth', (width, column) => {
if (column > 10) {
return 150;
}
})
Note that the first argument is the current width that we're going to modify. Later arguments are immutable, and additional information can be used to decide whether the data should be modified.
# Hooks
We refer to all callbacks as "hooks" because although they share some characteristics with events and middleware, they combine them both in a unique structure. You may already be familiar with the concept as we're not the only ones that use the hooks convention.
Almost all before
prefixed hooks allow the developer to return false
and, therefore, block the execution of an action. It may be used for validation, rejecting operation by the outside service, or blocking our native algorithm and replace it with a custom implementation.
A great example for this is our integration with HyperFormula engine where creating a new row is only possible if the engine itself will allow it:
hot.addHook('beforeCreateRow', (row, amount) => {
if (!hyperFormula.isItPossibleToAddRows(0, [row, amount])) {
return false;
}
})
The first argument may be modified and passed on through the hooks that are next in the queue. This characteristic is shared between before
and after
hooks but is more common with the former. Before something happens, we can run the data through a pipeline of hooks that may modify or reject the operation. This provides many possibilities to extend the default Handsontable functionality and customize it for your application.
# All available hooks example
Note that some callbacks are checked on this page by default.
# Definition for source
argument
It's worth mentioning that some hooks are triggered from the Handsontable core and some from the plugins. In some situations, it is helpful to know what triggered the callback. Did Handsontable trigger it, or was it triggered by external code or a user action? That's why in crucial hooks, Handsontable delivers source
as an argument informing you who triggered the action and providing detailed information about the source. Using the information retrieved in the source
, you can create additional conditions.
source
argument is optional. It takes the following values:
Value | Description |
---|---|
auto | Action triggered by Handsontable, and the reason for it is related directly to the settings applied to Handsontable. For example, afterCreateRow will be fired with this when minSpareRows will be greater than 0. |
edit | Action triggered by Handsontable after the data has been changed, e.g., after an edit or using setData* methods. |
loadData | Action triggered by Handsontable after the loadData or updateSettings({data: myData}) with the data property method has been called. |
populateFromArray | Action triggered by Handsontable after requesting for populating data. |
spliceCol | Action triggered by Handsontable after the column data splicing has been done. |
spliceRow | Action triggered by Handsontable after the row data splicing has been done. |
timeValidate | Action triggered by Handsontable after the time validator has been called, e.g., after an edit. |
dateValidate | Action triggered by Handsontable after the date validator has been called, e.g., after an edit. |
validateCells | Action triggered by Handsontable after the validation process has been triggered. |
Autofill.fill | Action triggered by the AutoFill plugin. |
ContextMenu.clearColumns | Action triggered by the ContextMenu plugin after the "Clear column" has been clicked. |
ContextMenu.columnLeft | Action triggered by the ContextMenu plugin after the "Insert column left" has been clicked. |
ContextMenu.columnRight | Action triggered by the ContextMenu plugin after the "Insert column right" has been clicked. |
ContextMenu.removeColumn | Action triggered by the ContextMenu plugin after the "Remove column" has been clicked. |
ContextMenu.removeRow | Action triggered by the ContextMenu plugin after the "Remove Row" has been clicked. |
ContextMenu.rowAbove | Action triggered by the ContextMenu plugin after the "Insert row above" has been clicked. |
ContextMenu.rowBelow | Action triggered by the ContextMenu plugin after the "Insert row below" has been clicked. |
CopyPaste.paste | Action triggered by the CopyPaste plugin after the value has been pasted. |
ObserveChanges.change | Action triggered by the ObserveChanges plugin after the changes have been detected. |
UndoRedo.redo | Action triggered by the UndoRedo plugin after the change has been redone. |
UndoRedo.undo | Action triggered by the UndoRedo plugin after the change has been undone. |
ColumnSummary.set | Action triggered by the ColumnSummary plugin after the calculation has been done. |
ColumnSummary.reset | Action triggered by the ColumnSummary plugin after the calculation has been reset. |
List of callbacks that operate on the source
parameter:
afterChange
afterCreateCol
afterCreateRow
afterLoadData
afterSetDataAtCell
afterSetDataAtRowProp
afterSetSourceDataAtCell
afterRemoveCol
afterRemoveRow
afterValidate
beforeChange
beforeChangeRender
beforeCreateCol
beforeCreateRow
beforeLoadData
beforeRemoveCol
beforeRemoveRow
beforeValidate
# The beforeKeyDown
callback
The following demo uses beforeKeyDown
callback to modify some key bindings:
- Pressing Delete or Backspace on a cell deletes the cell and shifts all cells beneath it in the column up resulting in the cursor, which doesn't move, having the value previously beneath it, now in the current cell.
- Pressing Enter in a cell where the value remains unchanged pushes all the cells in the column beneath and including the current cell down one row. This results in a blank cell under the cursor which hasn't moved.
# Related API reference
- Core methods:
- Hooks:
← Grid size License key →