Watchdog
Every non-trivial piece of software has bugs. Despite our high quality standards like 100% code coverage, regression testing and manual tests before every release, CKEditor 5 is not free of bugs. Neither is the browser used by the user, your application in which CKEditor 5 is integrated, or any third-party addons that you used.
In order to limit the effect of an editor crash on the user experience, you can automatically restart the WYSIWYG editor with the content saved just before the crash.
The Watchdog
utility allows you to do exactly that. It ensures that an editor instance is running, despite a potential crash. It works by detecting that an editor crashed, destroying it, and automatically creating a new instance of that editor with the content of the previous editor.
Note that the most “dangerous” places in the CKEditor 5 API, like editor.model.change()
, editor.editing.view.change()
or emitters, are covered with checks and try-catch
blocks that allow detecting unknown errors and restart the editor when they occur.
There are two available types of watchdogs:
- Editor watchdog – To be used with a single editor instance.
- Context watchdog – To be used when your application uses the context.
Note: A watchdog can be used only with an editor built from source.
# Usage
# Editor watchdog
Install the @ckeditor/ckeditor5-watchdog
package:
Then, change your ClassicEditor.create()
call to watchdog.create()
as follows:
In other words, your goal is to create a watchdog instance and make the watchdog create an instance of the editor you want to use. The watchdog will then create a new editor and if it ever crashes, restart it by creating a new editor.
A new editor instance is created every time the watchdog detects a crash. Thus, the editor instance should not be kept in your application’s state. Use the EditorWatchdog#editor
property instead.
It also means that any code that should be executed for any new editor instance should be either loaded as an editor plugin or executed in the callbacks defined using EditorWatchdog#setCreator()
and EditorWatchdog#setDestructor()
. Read more about controlling the editor creation and destruction in the next section.
# Controlling editor creation and destruction
For more control over the creation and destruction of editor instances, you can use EditorWatchdog#setCreator()
and, if needed, the EditorWatchdog#setDestructor()
methods:
The default (not overridden by setDestructor()
) editor destructor simply executes Editor#destroy()
.
# Editor watchdog API
Other useful methods, properties and events:
# Context watchdog
Install the @ckeditor/ckeditor5-watchdog
package:
And then change your editor and context initialization code:
To destroy one of the item instances, use ContextWatchdog#remove
:
# Context watchdog API
The context watchdog feature provides the following API:
# Configuration
Both EditorWatchdog
and ContextWatchdog
constructors accept a configuration object as the second argument with the following optional properties:
crashNumberLimit
– A threshold specifying the number of errors (defaults to3
). After this limit is reached and the time between last errors is shorter thanminimumNonErrorTimePeriod
, the watchdog changes its state tocrashedPermanently
and it stops restarting the editor. This prevents an infinite restart loop.minimumNonErrorTimePeriod
– An average number of milliseconds between the last editor errors (defaults to 5000). When the period of time between errors is lower than that and thecrashNumberLimit
is also reached, the watchdog changes its state tocrashedPermanently
and it stops restarting the editor. This prevents an infinite restart loop.saveInterval
– A minimum number of milliseconds between saving the editor data internally (defaults to 5000). Note that for large documents this might impact the editor performance.
Note that the context watchdog passes its configuration to editor watchdogs that it creates for added editors.
# Limitations
The watchdogs do not handle errors thrown during the editor or context initialization (e.g. in Editor.create()
) and editor destruction (e.g. in Editor#destroy()
). Errors thrown at these stages mean that there is a problem in the code integrating the editor with your application and such problem cannot be fixed by restarting the editor.
Every day, we work hard to keep our documentation complete. Have you spotted an outdated information? Is something missing? Please report it via our issue tracker.