Feature/question: unclear how to customize official plugins

Problem

We’re building our editor with Lexical, and we love both the developer experience and the fact that it ships with a nice suite of official plugins.

That said, it’s unclear how these plugins are supposed to be customized and extended. There is a very promising thread already discussing how to decouple nodes and plugins, so that devs can extend a node and replace the original ones. Then, plugins will make use of the extended plugin and still work (https://github.com/facebook/lexical/issues/1262), and that’s definitely very helpful.

However, there are still questions around how to customize other areas in plugins. Take the rich text plugin for example. We want our editor to support most of the functionality, but we don’t want to support some things like headings and text styles like strike-through.

For headings, we’re currently just not registering the heading node, and that seems to work for the most part. But there is a possibility that something will break because of that. In fact, when the markdown shortcuts plugin is used, it throws an error when trying to add a heading that way (basically typing # and hitting space), because the heading node is not registered.

And we’re not sure what to do about strike-through at all.

Of course, a solution is to just fork the plugins and customize them to our taste, but that seems overkill and introduces some complications like having to keep up with the upstream code and so on.

Potential solution

A solution that I think would work is simply accepting parameters on the official plugins.

These parameters could be classified into two main types: configuration and “hooks”.

• Configuration parameters allow devs to specify some options that the plugin will internally take into account. For example, for the rich text plugin, this could be a list of supported block styles, text styles, etc. Other examples could be enabling/disabling/customizing keyboard shortcuts, disabling some behaviors (like indent on tab), etc.
• “Hooks” allow devs to override parts of the plugin logic in a more liberal way, basically replacing what happens when the plugin tries to do X or Y, maybe with access to the original behavior through a callback that the user-provided function can still use in their custom logic.

I think something like this would be an amazing way to offer some customization without forcing users to either fork the plugin or use more “patchy” approaches like registering commands with lower priority that stop other commands on the chain from working (through returning true).

[acywatson]

Closing this for now, as we have a solution and a ref to the discussion in #1262

[acywatson]

It’s possible to adjust it with relatively low cost:

mutation listener or node transformer to replace created heading nodes with paragraph heading.replace($createParagrapNode().append(…heading.getChildren()))

@fantactuka - good point.

Something I’m still worried about with this approach (likely due to ignorance since I’m new to lexical) is that some edge case might be missing that could be the cause of hard-to-debug bugs down the road, especially as more plugins with complex interactions are added

This is also something we are thinking about and is a big part of the reason we haven’t yet done this:

and it’d be just perfect IMO if it even provided guidance on disabling some behavior with these methods.

The truth is, we tried to design an implement very powerful flexible APIs that can technically cover the majority of use cases, but our point-of-view on exactly how they should be used and how we should recommend that they be used is evolving. We’re still figuring out some of this for ourselves - how to keep the API surface simple and comprehensible while still enabling flexibility/extensibility.

I think there’s a middle ground though, where we could at least give some hints about where to look for this kind of override functionality in the docs, even if we aren’t yet ready to explicitly recommend that everyone do it this way.

Would be interested in your feedback as you progress here.