Feature: Support AbortSignal interface for listeners

[levensta]

Description

I suggest adding support for the signal option for each listener and the mergeRegister function, which will accept the AbortSignal object. An abort event subscriber will be added for the passed signal option, and the cleanup function will be called

Example implementation

export interface LexicalListenerOptions {
  signal?: AbortSignal;
}

class LexicalEditor {
  registerUpdateListener(
    listener: UpdateListener,
    options: LexicalListenerOptions,
  ): () => void {
    const listenerSetOrMap = this._listeners.update;
    listenerSetOrMap.add(listener);

    if (options && options.signal instanceof AbortSignal) {
      options.signal.addEventListener('abort', () => {
        listenerSetOrMap.delete(listener);
      });
    }

    return () => {
      listenerSetOrMap.delete(listener);
    };
  }
}

Impact

The AbortController API is compatible with other Web APIs such as fetch and EventTarget, so adding a signal to lexical listeners will simplify the management of the lifecycle dependent on asynchronous operations, including user events.

This can be especially useful for applications that use lexical editors outside of React with its familiar useEffect for lifecycle management. At the very least, it will reduce boilerplate code where cleanup functions from lexical listeners are already used together with AbortController

References

• Lexical Listeners
• AbortSignal
• signal option in addEventListener
• signal option in Fetch

[etrepum]

There aren’t really any situations where you’d want to register a handler based on something like a fetch. A concrete example with a real use case would be a much better way to make the case for this feature.

Extensions do support abort signals but the other way around, it provides an abort signal that you can use that’s coupled to the lifecycle of the extension on that editor which is actually useful for things like fetch or listeners for the document.