Managing data in custom decorator node

[Othman-dev]

Hi everyone,

I created a custom node extended from decorator node, the goal is pretty simple, a table with 2 columns and a customizable number of rows (at least 2) for this purpose I created the following
export type CustomField = { __label: LexicalEditor, __value: LexicalEditor }

`
export class MetadataNode extends DecoratorNode {
__projectLabel: LexicalEditor
__projectValue : LexicalEditor
__authorLabel: LexicalEditor
__authorValue: LexicalEditor
__customFields: CustomField[]

constructor ...
`

So in this case it is called MetadataNode and the two mandatory rows are project and author after that you have a plus button at the bottom of the table, similar to Lexical existing Table and a delete Icon inside each customField row, so everything is working just fine except the delete function.
When I delete a custom fields, whichever I pick will delete the last one in the component but if I check the editor with my save plugin (which saves editor as JSON) I can see that the one I was suppose to delete is actually disappearing from the data (but not visually from the component), and the last one is still present inside as JSON but data is corrupted, mainly emptied.
As an example here is an abstraction of this behavior.

Initial state:

projectLabel | projectValue
authorLabel | authorValue
custom 0 | 0 x
custom 1 | 1 x
custom 2 | 2 x
custom 3 | 3 x

if I click on second custom field (index 1 inside the array), to delete it:

projectLabel | projectValue
authorLabel | authorValue
custom 0 | 0 x
custom 1 | 1 x <---(clic)
custom 2 | 2 x
custom 3 | 3 x

I end up with:

projectLabel | projectValue
authorLabel | authorValue
custom 0 | 0 x
custom 1 | 1 x
custom 2 | 2 x

But i can tell that I click on index 1 since my delete function is like this:
`
removeCustomField (index: number): void {
const writable = this.getWritable()

console.log(index)

writable.__customFields.splice(index,1)

}
`

and if I extract my data to save it in my database, I can see every customFields but custom 1, as well as custom 3 containing empty LexicalEditor but still present.

This should be pretty close from experimental table and its rows/columns behavior but I am guessing I am missing something, so I maybe someone here would have a clue ?
I am willing to expand my explanation and give more information if necessary.

Thank you for you time.

edit: Code insertion seems wrong everything inside back ticks is suppose to be code of course.

[ivailop7]

Blindly guessing here, since I need to see more code, but if you have state inconsistency after object mutation, one thing to check is if in your methods where you mutate the state, you are using this.getWritable() there are a number of examples in the playground. Given the description of your problem, it sounds like copy-pasting the table plugin and nodes and deleting all the code except the row add and row delete might get you to closer to your goal.

[Othman-dev]

Hi,

Sorry for the long reply, I had to put that project aside, but I have news.

patch: After showing the project to my team we found out that by returning true to updateDOM function inside the custom node discussed in the first post. The component would work as expected. So I was wondering what exactly does this function since it unlocked this issue for me but I can see that in the playground, tables updateDOM function always return false and work the same way.

@ivailop7 : I have to recreate another component so I will be trying your idea in the following week. Which I am pretty sure will work, since it does in the playground. And I am still curious about my patched case if you have any clue I would be glad to share part of my code to find out what I did not understood.

[ivailop7]

Sorry, don't know how I can help further on this one. Good luck with the new component. Let us know how it goes!

[Othman-dev]

thank you, I will.

[Othman-dev]

posterity post:
Found my problem, inside decorate function I forgot <suspense><suspense> so component would fail rendering I guess.
Now updateDom() return false as it should and I don't see any issue other than that.

So that's that.