Skip to main content

FAQ

What's the compatibility story?​

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

Lexical Builder Plans are only compatible with editors created using the Lexical Builder API (buildEditorFromPlans, or an abstraction that uses it internally such as LexicalPlanComposer).

See the Migration Guide for more detailed examples!

Why is it called a Plan 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 Plan could not be colocated if they were both called Plugin!

What about lazy loading?​

Lazy loading does not need any special support!

For an example of how to do lazy loading in Vanilla JS, see the register property in EmojiPlan.ts.

Lazy loading in React could be as simple as using React.lazy, see the Component output in BuilderGraphPlan.tsx

Note: The Plan 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 Builder. 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 Plans written for either of these to be loaded into any editor regardless of what framework the page is using.

When you depend on a Plan that depends on ReactPlan, you will get a runtime error if a React provider is not present (LexicalPlanComposer or ReactPluginHostPlan). Think of it like an unsatisfied but required peer dependency. This way you won't get confused if you add a plan 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 Plan tree
  • Track which config came from which Plan (e.g. which node, which theme property, etc.)
  • Track which commands/listeners/etc. were registered by which Plans (would require editor instrumentation)