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
MoveBlockandReplaceBlockoperations 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!
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime