Skip to main content

FAQ

What's the compatibility story?​

All Legacy Plugins (React Components) are compatible with Lexical Extensions!

Lexical Extensions are only compatible with editors created using the Lexical Extension API (buildEditorFromExtensions, or an abstraction that uses it internally such as LexicalExtensionComposer).

See the Migration Guide for more detailed examples!

Why is it called an Extension instead of a Plugin?​

Legacy reasons. Historically, Lexical has used the term Plugin to refer to a React component that adds behavior to the editor. Transitioning this word to another meaning would be confusing.

It would also be a tricky transition for public APIs, since the ideal names for exports are already taken, so the legacy Plugin and the new Extension could not be colocated if they were both called Plugin!

What about lazy loading?​

Lazy loading does not need any special support! All of the functions that you implement with extensions must be synchronous, but your register or afterRegistration function can perform an asynchronous import(), network calls, etc. You just need to make sure that the dispose function that you return can manage the cleanup appropriately. You can also use getSignal() on the state to get an AbortSignal which may be more convenient than tapping into the dispose function.

This is similar to how you would use React.lazy to defer loading the implementation to when it is used.

See the extension-vanilla-tailwind example for a demonstration for how this can be done. Open in StackBlitz

note

The Extension itself must be synchronously imported before creating the editor. Lexical needs all editor configuration (including nodes) up front. This is no different than without Lexical Extension. The Lexical core would need significant changes to allow configuration changes to an editor at runtime.

How do we prevent all of the frameworks from being loaded?​

Vanilla JS and React have first class support in Lexical. Lexical Builder provides a path for Extensions written for either of these to be loaded into any editor regardless of what framework the page is using.

When you depend on an Extension that depends on ReactExtension, you will get a runtime error if a React provider is not present (LexicalExtensionComposer or ReactPluginHostExtension). Think of it like an unsatisfied but required peer dependency. This way you won't get confused if you add an extension that requires React but it never renders correctly because React isn't set up properly.

Other frameworks can use the functionality exposed by Lexical Builder to provide their own integrations in a similar way. Supporting DecoratorNode subclasses in multiple frameworks is not currently supported, or planned to be supported, because I am pretty sure that you can use mutation listeners for the same purpose. Perhaps the decorate method could even be deprecated at some point!

How will this interact with Lexical Dev Tools?​

All of the Builder metadata is present at runtime, and is is present on the LexicalEditor instance with a well-known symbol so that the dev tools can access it. There are many things that could be done, here are a few examples:

  • Show a diagram of the Extension tree
  • Track which config came from which Extension (e.g. which node, which theme property, etc.)
  • Track which commands/listeners/etc. were registered by which Extensions (would require editor instrumentation)