Use custom DOM node with inline decorations

I am currently looking for a way to wrap an inline Decoration in a custom DOM element. I saw that there is a way to define the DOM element type of the wrapper via the nodeName attribute, but I need to create the DOM element myself.

My use case is to add a tooltip to the decorated text. This tooltip needs a custom click handler and will potentially be rendered using ReactDOM. The tooltip DOM element would wrap the decorated text and handle the show/hide logic when hovering over it. What would be the best way to achieve this? If this isn’t currently supported, I think that being able to specify a dom attribute as an alternative to the nodeName attribute would be nice.

That’s not supported, since the editor may need to create multiple such elements.

But you could add a handler to the whole editor and inspect the event’s target node to see whether it applies to your decoration node.

I suppose this happens in the case of overlapping decorations? I didn’t think of that as my use case does not allow overlapping decorations. What if the dom attribute was a method which returns a DOM node for the decoration to use. That way it could be created multiple times. Or are there other reasons why this would not be possible? Supporting custom DOM nodes would also make it necessary to expose a destroy method like node views do.

I think I could make it work using this approach, but unfortunately I won’t be able to reuse the tooltip component that I already have, so I’ll have to reimplement most of the tooltip logic, which isn’t ideal.

I’m not sure how many use cases would benefit from custom DOM nodes in decorations, so it might be better to keep it simple if it adds too much complexity in the implementation or API.

Rather, when the decoration covers multiple inline nodes or inline content spread across multiple textblocks.

Sorry, no, the code as it is can be cleanly incremental (it does the minimum amount of DOM updating needed) because it knows everything about the nodes it is creating, and I’m keeping it that way.

Thanks for clearing that up! I can understand the decision not to support this use case.