I can't make it to the meeting, but here I layout the concerns I have around what we need to do with the table, I hope this helps to get to a good enough first step so we can publish tables in the next version:

Table Lifecycle

This is what I understand the table lifecycle should be:

From editor to backend

user creates a table in the editor in a draft

the draft is saved

the user publish the document

we convert the editor table to HMTable

we add MoveBlock and ReplaceBlock operations that include the table block and all its children blocks (cells, columns, rows...

done, the document is published

From backend to editor

user loads a document

for a table block, we convert the HMTable to editor table

we render the table in the editor and enable editing right away (for editors)

I think this lifecycle is pretty straightforward and we should all have consensus over this.

Table Transformations

Here's where most of my concerns are, so I will try to explain all the scenarios I don't know what should happen. This is all considering we are comparing final states to get the operations that happen in the editor, because we are not translating to Operations while the user edits the document.

About comparissons

I believe we need to have a deterministic process to compare final states for tables:

convert editor table to HMTable

compare rows -> create operations

compare columns -> create operations

compare each cell -> create operations

I'm not saying it should be this, what I'm saying is that is should be the same and isolated, so it will be easy to test.

Scenario 1

when a user:

moves a row

then moves a cell to another place that was part of the row

how are we going to understand that those row moves happen and not consider independent cell moves?

I guess because we are adding IDs to rows then we can derived the move from it?

Scenario 2

when a user:

have a 3x4 table

creates 3 more columns

reorder 2 rows

add content inside the cells

will all those operations will translate to:

3 column move operations

2 rows move operations

6 replace cell operations

Do we need to also create a move operation for each cell to create it?

Scenario 3

considering that rows and columns have Ids and are considered blocks, we can say that those blocks can only be moved (and created) and deleted right?

when we have multiple rows and cell moves, should we consider an order in which we need to send the operations? rows first and then columns or does not matter?

Scenario 4

because we track deletes and send them at the end of the operations list, should we do the same here or maybe something different?

Scenario 5

we need to make sure that inserting rows or columns in the beginning of the table, do not shift the rows and columns IDs down. this will be really bad for table integrity. We had this issue on normal lists in the past.

Scenario 6

how are we storing row/column IDs when we copy tables from the editor? because we might need to keep track of that so when pasting we use the same IDs.

this are most of the concerns I have around tables. hope this helps and you can get to good conclusions!