RFC: Tables in the Lexical Editor

[GermanJablo]

Summary

This RFC explores the possibility of enhancing the table functionality within the Lexical editor by allowing users to integrate their preferred table libraries with minimal modifications. Below is a curated list of grid, table, and spreadsheet libraries reviewed during research:

• tanstack/react-table
• ag-grid
• handsontable
  
• jspreadsheet
  
• regular-table
• react-data-grid
• reactgrid
• DevExtreme
• React-aria table
• React-aria grid
• DHTMLX Spreadsheet
• Luckysheet
• Univer
• glide-data-grid
• fortune-sheet
• deephaven grid
• datagridXL2
• rowsncolumns
  
• react-datasheet
• Grist
• DataTables
• SlickGrid
• CLusterize
  
• Baserow.io
• sheetxl

These libraries offer a broad range of complex features such as virtualization, keyboard navigation, accessibility, sorting, filtering, resizing, creating, deleting, reordering, hiding rows/columns, protected ranges, formulas, and more. Many of these libraries are maintained by dedicated teams of engineers, highlighting the complexity and effort required to develop and maintain them.

Why is This Relevant to Payload?

Currently, Payload uses the official Lexical table package. In Lexical there are two ways to model data:

• DecoratorNode: can be any React component
• Other nodes: basically each node has to represent a node in the DOM.

The table package uses the second approach. That's why you have TableNode, RowNode and CellNode that mimic table, tr and td. While functional, this approach ties the editor tightly to the Lexical-specific implementation, limiting flexibility and customization.

Proposal: Decoupling Table Implementation

I've been advocating for a while now that text editors shouldn't waste time maintaining table and code blocks. A text editor is arguably already the most difficult UI component to develop, so it's good to decouple it from the responsibility of tables and code editors which also have so many different implementations and endless possibilities.

I'm glad that Payload hasn't incorporated the Lexical code block, and instead, the idea of ​​embedding the Monaco component is being explored. I would like to propose doing the same with tables.

My idea is that, regardless of the table library we choose, the serialization of the DecoratorNode (methods importJSON and exportJSON) will be to a versatile and universal table format, such as CSV.

This approach allows seamless switching between table libraries by serializing to a common format, eliminating the need for migrations or breaking changes.

We would also have to decide the format of the cell content, which could be Lexical-json, markdown or html, but that discussion can take place later.

Benefits

• Flexibility: Users can choose the table implementation that best suits their needs.
• Ease of Integration: Switching table libraries would be straightforward, requiring minimal modifications.
• Reduced Maintenance: Decoupling tables from the core text editor allows Payload to focus on the text editing experience without being bogged down by the complexities of table implementations.
• Consistency: A universal serialization format ensures smooth transitions between different libraries.

Considerations

• Selection: For technical reasons, DecoratorNodes in Lexical are wrapped in a content-editable: false. That means that the selection cannot start inside the table and end outside, or vice versa. In my opinion, this may turn out to be more of an advantage than a disadvantage. I don't see why anyone would want to start the selection inside and end it outside the table.
• Undo managers and RTC: making the undo manager work seamlessly between the editor and its DecoratorNode often has some challenges. Also, if you want to incorporate RTC, there is currently no way to do so in DecoratorNode that does not involve LWW resolution. I don't think it's a non-starter, but it's something to keep in mind.

[GermanJablo]

I'm abandoning this idea.
The data model of a table is very dependent on its implementation. Anyone can create their own feature table using a decoratorNode. Making it easy to migrate from one of these tables to another is something I don't think is worth the effort.