Feature: Scroll for table

[denindka]

Description

It would be great if the table had its own scroll bar. Right now, the scroll affects the entire document, which is not very convenient.
The video shows an example of how this is implemented in other projects.

Screen.Recording.2024-07-31.at.12.44.41.mov

[keiseiTi]

I tried to solve this problem, but the createDOM method of ElementNode does not support nested elements

[keiseiTi]

Can ElementNode add a method createDOMContainer to create a DOM container that wraps the DOM ? @zurfyx

[agscripter]

Hey, It would be great to have this feature. +1

[lxzmo]

+1

[bilobom]

+1

[alphaCastor]

As quick workaround (before we will have nested elements support) you can use css:

table {
  max-width: 100%;
  overflow: auto;
  display: block;
}

And keep in mind that whole editor container must have width

UPD. Change columns size wont work :(

[CojocaruCristi]

[CojocaruCristi]

+++++++

[MaslovRustislav]

Fell into the same issue, please help!

[yaojiu19]

I am trying to solve it by customElements, but were some issues. pr: #6587

[GermanJablo]

Thanks to @yaojiu19 for offering to contribute to this issue, although that PR doesn't solve the problem in "the lexical way" as the maintainers mentioned there.

I'm willing to solve this issue myself, but first I'd like to know if the Lexical team thinks it's ok to introduce a new ElementNode that acts as a wrapper.

[etrepum]

@GermanJablo The biggest problems with #6587 are that there are exactly zero lines of tests, documentation or examples. There's no way to know whether it works at all other than to fill in all the missing pieces. Does it say it solves a problem? Sure. Does it actually? Does it break anything for people who are using custom nodes with however Lexical interacts with them today? Who knows. Can't possibly approve it in its current state.

Custom elements aren't used or tested anywhere else in Lexical, and that it's unclear there wouldn't be other problems with this approach (regarding selection, events, or anything else). A different approach that did not add custom elements was in #5930 / #5981 but that also stalled in part because you questioned what utility it would have, so it too is missing all of the finishing work that would have to be done before anyone knows if it is a real solution or not.

[GermanJablo]

I don’t see why I would be responsible for PR 5930 being stalled. If that's the case for some reason, I encourage anyone who wants to continue it :)

As far as this issue is concerned, what I am suggesting is adding a new ElementNode, which seems to me to be the simplest solution.

[etrepum]

I'm sure the large part that it's just a hard problem to solve, but your feedback on that PR was the only negative feedback and may have contributed to them losing steam. Adding a new kind of ElementNode that has components that are otherwise "invisible" to the reconciler is more or less equivalent to having a DecoratorElementNode, so going back to that PR and looking more closely might be worth your time. Note that any decorator can render all of its children directly in createDOM/updateDOM and return null from its decorate method if there isn't a need for a framework managed portal. I look forward to seeing what you come up with!

[GermanJablo]

I have opened a PR that closes this issue: #6713.
Comments and observations are welcome.

[agscripter]

Hi @GermanJablo, great job, I love this feature.

Do you believe it's possible to have a table inside the document that its width is larger than the document and the table can be shown like in Quip:

As you can see, the table width is larger than the document content, but still the table is shown without the horizontal scroll.
Perhaps with your implementation it's possible to achieve this result as well.

[GermanJablo]

Thanks @agscripter. Yes, that should be possible by playing with the paddings

[yaojiu19]

now I implement it through plugins

create a scrollbar outside the editor by watch the width of root element and the table