Behaviors
Behaviors are allow you to customize how users interact with the editor by hooking into events during the editing experience.
All behaviors follow this process:
- Listen for an event.
- Use a guard to decide if they should run or not.
- Trigger a set of actions to perform on the editor.
This pattern is influenced by Statecharts.
Behaviors are defined with the defineBehavior
helper. Here’s an example event from the behavior guide:
Revisiting the three step process above:
on
listens for the event.guard
handles the conditional.actions
sends, or invokes, the desired actions.
Events
Whenever you enter text into the editor, activate a toolbar button, or anything else happens in the editor it sends an event.
There are two categories of Behavior Events:
- Native Events: Events that come from the browser or device directly.
- Synthetic Events: Abstracted events specific to the editor.
The Behavior API uses events to trigger actions by listening for a specific event.
Guards
A guard is a condition that helps the behavior determine if it should perform the actions.
The guard
key expects a response or false
. The example above shows a simple truthy guard. Here it is again:
Guards can also return parameters that you can access when firing an action.
Passing parameters allows you to reuse conditional behavior, such as selecting part of a string, without rewriting the logic.
Guards are optional. This means it’s possible to create an unconditional behavior that always runs when an event occurs. The “soft return” behavior build into the PTE is one example:
This behavior listens for soft break events and uses the insert.text
action to insert a \n
instead to prevent splitting text blocks with Shift+Enter
. These unconditional behaviors are rare and you’ll mostly encounter conditional behaviors.
Actions
Actions make things happen in the editor. This is where you change the standard behavior by modifying actions before they occur or by circumventing them completely. You’ve seen actions in some of the guard examples above.
The actions
key expects an array of behavior action sets. As with guards, you have access to the event
and context
.
So far we’ve only seen examples that invoke a single action, but you can send multiple actions or sets of actions from a single event.
Raise events within actions
While some actions share names with events, it’s important to remember that actions don’t send events. To send an event with an action, use the raise
action type or the raise
helper. This is useful for chaining behaviors and default events.
Selectors
Selectors are pure functions that derive state from the editor context (context
in the examples). A collection of selectors is included with the core library.
The core selectors are useful helper functions for checking conditions of the editor, finding selected text, and more. You can manually do anything a selector can do by parsing the editor context.
Behavior Examples
Browse the existing behaviors, or check out the Behavior Recipes documentation for examples of real-world behaviors.