Nodes' data structure

[unbeauvoyage]

I want to decide on my nodes' structure and thinking about namespacing my variables in a field named __meta (or __data) so that all the values will be accessed and mutated like, say, __meta.xOffset, __meta.componentToRender etc. I've extensively studied the docs and lexical-playground examples.

Is this a good approach considering my reasoning below, or should I just stick to the existing examples? Is there anything I might be missing architecture-wise, performance-wise, state-management-wise, lexical-internal-stuff-wise or whatever-wise?

Part of my reasoning:

1. I am worried that a future lexical update will introduce a field name that will clash with one of mine, of which there will be hundreds. (Should I even be worried about this?)
2. I made a generic base node class which has import/export DOM/JSON methods, which reduces error surface and I can just use in the child class. (Types are not an issue, I strictly type the child classes. But still, because I don't have explicit fields on the node, could I be missing something here typescript-wise?)
3. I have experimented and found that dumping everything in a __meta namespace does not seem to have any particular catch when it comes to node reconciliation or with react component rerenders in the decorate method. (So, I thought, why not? But still, I might be missing sth.)
4. I write my own base classes extended from lexical's base classes to reduce boilerplate. Overall, is there anything against this; should I just go with always directly extending lexical's base classes at the expense of more boilerplate? I know this is slightly out of scope of lexical and a very general question, yet I am asking in light of any lexical particularities I might be ignorant of.

Any other pros and cons, or architectural recommendations are welcome.

(Just such a wonderful library, have fully migrated to it and been building on it. Now trying to decide on a robust architecture.)

[etrepum]

1. Probably not something to worry much about. If/when lexical adds new properties to the base nodes it would likely be part of a bigger backwards incompatible change that you'd have to refactor for anyway. You could also use a single underscore for application properties instead of two and never have to worry about it at all.
2. Hard to say whether you're missing something or not without seeing the code, but it is likely that import/export/clone best practices will change in the future (possibly in a backwards incompatible way)
3. Should be fine as long as clone is implemented correctly, you want to make sure your __meta object is not shared across versions of that node (e.g. this.__meta = {...prevNode.__meta} is likely fine, assuming there's aren't mutable values in there that would also be shared, in which case this.__meta = structuredClone(prevNode.__meta) might work)
4. As long as your nodes have one of TextNode, DecoratorNode, or ElementNode in their class hierarchy I don't see any problems

[unbeauvoyage]

Thank you. That answers all my questions. Just to provoke further valuable advice:

By convention, we prefix properties with __ (double underscore) so that it makes it clear that these properties are private and their access should be avoided directly. We opted for __ instead of _ because of the fact that some build tooling mangles and minifies single _ prefixed properties to improve code size. However, this breaks down if you're exposing a node to be extended outside of your build.

Regarding point 1, I also had thought of using single underscores, but in the lexical docs there was the part above (regarding the tooling) about the double underscore convention. So, I thought, single underscore might be better to avoid. But I get the point.

And the worry that I had about refactoring is not about app refactoring, which we are fine with. It is about the would-be inconsistency between node fields and serialized data that will have been stored in the db. (But that is not a big deal, since, I guess, that should be taken as a given and lexical provides very convenient import export methods anyway.)

Special thanks for the third point. I am sure that would have tripped us over down the road, had I not asked this question.

Again regarding my third question but from design perspective to invoke knowledge and experience (perhaps also a little) beyond lexical scope:
Does it make sense to namespace all fields in a field named __data (or __meta), just in order to avoid having to write separate import/export methods (by extending my own generic base class)? Or is it still better to be explicit about field names at the expense of writing import/export separately for each node, every time?

(I would greatly appreciate any other relevant advice, but I got the answer to my original question.)

[etrepum]

The referenced _ vs __ convention concerns are only relevant if you are distributing a package for others to use where you have no control over the tools and configuration they're using.

Node fields and serialized data are separate in Lexical, there's no introspection/reflection used (except in collab and that's likely to change in a backwards incompatible way since it's a bad approach), so the renaming wouldn't affect them at all. The import/export methods can do any sort of transformation, so long as the type is there in the output.

Generally speaking, the number of different nodes a project implements is not that big so the boilerplate involved is usually not too bad, although it feels that way at the beginning when you're paying most of that cost. There are performance benefits to having it be less dynamic, and with the current class design there isn't really a backwards compatible way to remove all of the boilerplate (particularly the static clone and importJSON methods) without sacrificing a fair bit of performance.