Reasons for architectural decoupling

[abstractalgo]

I just started using Lexical and was pretty confused by a separate need for registering Nodes and using Plugins. For composability's sake, I would expect that every Plugin would register its own nodes that it needs in order to function properly.

Q1: is there a reason why initialConfig.nodes is separated from <WhateverPlugin>?

---

Related to that breakage of encapsulation and composability, I noticed that playground example app has things spread out for registering nodes, UI components, plugins and it's sometimes using @lexical/react/LexicalWhateverPlugin yet sometimes using @lexical/something packages.

Q2: So, similarly to the first question - is there a reason for this kind of architecture, or is it just a matter of the current state of things and is something that will [likely] change over time?

Thank you 🙌

[echarles]

Q1: is there a reason why initialConfig.nodes is separated from ?

I asked my self the same question. Maybe to avoid potential multiple registration of the same node type? The multiple registration could be anyway managed, so I don't see ATM reasons for this separation.

Q2: So, similarly to the first question - is there a reason for this kind of architecture, or is it just a matter of the current state of things and is something that will [likely] change over time?

Although potentially confusing, I better understand that separation. I guess the @lexical/something (eg.@lexical/list) provides primitives for a feature (list) independent of React.js. Then the @lexical/react/LexicalListPlugin is the effective implementation of the React plugin. This allows other frameworks like Vue.js to implement let's say @lexical/vue/LexicalListPlugin that reuses .@lexical/list

[acywatson]

Although potentially confusing, I better understand that separation. I guess the @lexical/something (eg.@lexical/list) provides primitives for a feature (list) independent of React.js. Then the @lexical/react/LexicalListPlugin is the effective implementation of the React plugin. This allows other frameworks like Vue.js to implement let's say @lexical/vue/LexicalListPlugin that reuses .@lexical/list

This is right!

I just started using Lexical and was pretty confused by a separate need for registering Nodes and using Plugins. For composability's sake, I would expect that every Plugin would register its own nodes that it needs in order to function properly.

Q1: is there a reason why initialConfig.nodes is separated from ?

We have tried to get rid of this node registration API on the Editor a couple of times and we are looking to improve this - it's definitely not ideal that Nodes used by a plugin have to be separately registered during editor creation. The reason for this API originally had to do with the way we were handling deserialization. We need a way to map Node string types to the class that they should be deserialized to from JSON. This API significantly predates the plugin system and the current deserialization process (where the nodes specify their own deserialization logic. However, when we tried to drop this API when we rewrote serialization/deserialization a few months ago, we ran into something (sorry I can't remember what) that made it more complex to change than we had time to deal with at the moment.

Sorry I can't recall the exact constraints at the moment - I guess the real question is around why exactly it has to be done during Editor creation and can't be done during plugin initialization. This is one of the areas we're targeting for improvement before the V1 release.

@zurfyx in case he can provide more context.

[luanmm]

What I understand from nodes/plugins separation is related not just to the fact that "plugins use nodes", but because Lexical needs to know all its nodes to be capable of read the state and process it. And, in the other hand, plugins can be optionally defined based on some constraints (like if it is in editing mode or not), but nodes are needed despite any constraints.

Another thing is that (in my point of view) multiple plugins could use the same node. Let's say you have an "image" node, that can be inserted through a generic toolbar, but have another plugin to resize it, another one to draw over it, etc.

[abstractalgo]

Thank you for the replies so far, they do help make more sense of some of the decisions.

If there's a ticket to track the work around that initialization part, I'd be very much interested in being able to track progress on it. Thanks!

[jtmarmon]

Just wanted to mention that I find this decoupling extremely helpful, as it's enabled us to parse and interact with the document on the server for our app without needing to polyfill all the FE things.