Wrapping a CodeNode with a React Component

[BrianUribe6]

I've been working on adding a toolbar on every code block. I've looked at the code on the playground, where you listen to mouseover and position the "code actions menu" absolutely based on the code blocks coordinates. For my use case, it would be better if I could insert a React component that surrounds every code block.

<ActionBarWrapper>
  <ActionBar />
  <pre>
    <code>
     ...
    </code>
  </pre>
</ActionBarWrapper>

I tried creating a custom node by extending CodeNode and overriding its createDom method, but I was unable to figure a workaround for inserting a react component.

Is it possible to do something similar to a DecoratorNode on a CodeNode or are there any workarounds besides hacking it together with absolute positioning?

[yf-yang]

What about directly write your React wrapper in the decorate() function? (You need to make it work with RichTextPlugin).
https://lexical.dev/docs/concepts/nodes#extending-decoratornode

[yf-yang]

OK, I come up with an idea, write something like a MyActionBarPlugin, it has a state called codeNodePortals. Inside the plugin, register a editor state listener, then whenever the editor state changes, iterate through the editor node tree, find those code nodes and record those empty div ids in the state codeNodePortals. Then, for each empty div of codeNodePortals array, create a react portal to mount your react component and return those portals from your MyActionBarPlugin.

Well, I think that is also hacky. I don't like the performance loss you pay for iterating through the whole tree to find desired nodes whenever the editor state changes (although that could be improved slightly with significant complexity by checking the dirty nodes only).

[yf-yang]

Ah, query selector may help. Register the editor state listener, then apply query selector each time and update the state (not sure how that could be memoized to eliminate unnecessary React rerenders, maybe combine the query selector and div ids, this approach makes more sense.

[yf-yang]

OK, I think the solution you offer doesn't work. If mount the React portal to the div, that's exactly how DecoratorNode works as React Portal can only be a leaf of the HTML tree. In that way, you cannot add any Lexical node to your React portal, so you cannot benefit from Lexical's LexicalNode handling mechanisms. Instead, you have to manage those child div's yourself. Is that what you want?

In other words, for branch of a tree (ElementNode), React portal cannot replace them. It can only replace leaf nodes.

[BrianUribe6]

Your approach is very inline with my thoughts. Instead of listening to the editorState, I was thinking on registering a mutation listener on CodeNode. When a CodeNode is created I portal my react component into that node's container, and when it's destroyed I delete it from my state.

It is perfectly fine for me if I'm not able to inherit any behavior from LexicalNode. However, I still wish we had a more sane way to handle this.

[ryanheise]

In other words, for branch of a tree (ElementNode), React portal cannot replace them. It can only replace leaf nodes.

Doesn't createPortal append it as a child of the target rather than replacing anything? In that way, it is possible to use document.body as the target and it will be appended without replacing anything already in the body.

That said, this didn't actually work when I tried to target an element node within the content editable tree. I can successsfully portal into a DecoratorNode, but not an ElementNode (although I can portal into any non-empty element outside the content editable).

@yf-yang do you know of any reason this wouldn't work within the content editable?
@BrianUribe6 did it ultimately work for you?

The only thing I can think of is that Lexical is doing some additional management on element nodes that interferes with portalling.