This is a lower-level API. Lower-level APIs are not recommended for most projects, and may not be available on all plans. See our page on recommended deployment patterns for more information.
Event Question Editor API

revisionHistoryState:change

Triggered when current state of Undo/Redo changes. State changes are triggered by the following actions:

  • Clicking the Undo or Redo buttons.
  • Calling undo() or redo() public methods.
  • Changing any UI field (on blur).
Use this event to manage custom button states (i.e. if not using default undo/redo buttons).

This event gets fired twice per state change:

  • The first event fires with both booleans set to false, to indicate both buttons should be disabled (see right).
  • The second event fires with updated states once the first has completed. E.g. after changing a field, canUndo will be true and canRedo will be false (see right).

New snapshots are typically very fast so both events will trigger rapidly, but undo/redo operations can take some time. It is important to listen to these events and prevent or ignore further undo/redo commands until the current operation completes.

Note if you call the public method off() with the argument revisionHistoryState:change, it will disable the default undo and redo buttons.

Callback arguments

  • undo_state object
    An object that contains:
    • canUndo: boolean, indicates whether there is a previous state that QE can be reverted to via the undo() public method.
    • canRedo: boolean, indicates whether there is a newer state that QE can be restored to via redo() public method.
    Sample data:
    (first event): {canUndo: false, canRedo: false}
    Sample data (second event): {canUndo: true, canRedo: false}
Was this article helpful?