workflow on how to implement local note deletion/unstacking and undoing those changes

[Schwehn42]

Hi all, regarding #2350, I'm currently contemplating on how to approach this problem.

Current situation:

• Action.DeleteNote just sends the API call
• the note is only deleted after Action.DeletedNote is invoked via websocket

some thoughts about the flow:
On delete:
new Action.LocalDeleteNote:

• change state and delete note(s) just like before on Action.DeletedNote
• Delay actual API call by 5s
• New Action.UndoDelete:
  • Requires information about note and its (former) children (=> might need to adjust state from Note[] to something more complex to keep track of local deletions/unstackings, e.g. {notes: Note[]; actionQueue: {note: Note, action: "delete"|"unstack"}[]}
  • Needs to re-add note to state and find children on board to re-add to stack
  • If notes that belonged to a deleted stack were deleted in that time (locally or remotely), that must be handled (e.g. ignore those)
  • All has to happen locally, just requesting the current server state to easily reset would lose information if multiple notes have been locally deleted
  • also cancel API call
• After API call and Action.DeletedNote:
  • if it was deleted locally before (you know this by looking at actionQueue in state) remove that entry and return state
  • if not, it's a note deleted remotely. in that case, just delete the note like it's currently done.

On unstack:

• Should be more or less the same workflow as deletion (hopefully)

Some more points:

• I was also thinking of just pretending to delete the notes and hiding them instead, which sounds much easier at first glance, but will be problematic e.g. deletion of note stack parents, or just unstacking.
• Action.LocalDeleteNote might not be necessary, maybe using the current Action.DeleteNote will be enough but I'm not certain, when drafting I wanted to have a clear line between the functionality of the Actions though.
• Also if we really do have to change current NoteState in order to keep the information required, refactors in the whole project will be required, i.e. wherever notes are used, notesState.filter(...) would become notesState.notes.filter(...).

As you can see, this problem is a lot more complex that I intitially anticipated, so I would be grateful if you had any ideas or pointers how to improve my approach :)

[Schwehn42]

Update: After talking about this with @timengel, we think it would be an easier and more consistent solution to keep doing the changes in the backend right away, therefore instantly deleting/unstacking a note for all users, but also keeping a local action queue in order to undo those changes using the backend within the 5s period.

[Schwehn42]

Such an approach would of course require some backend changes as well.
When reverting the deletion of a note, just recreating a note with the same text is not sufficient. The reason for this is that information about the NotePosition (i.e. stack and possibly rank) are also required, which the standard REST Create Note Request does not offer atm.
On the frontend side, one needs to keep track of all initially locally deleted notes in an ActionStack. This is just like the ActionQueue in the first approach, which means that upon deleting a note locally, it would add all note information to the noteState.actionStack and remove the entry after any incoming note action contains the respective note (so like a successfull Action.DeletedNote or Action.UpdatedNotes).

[brandstetterm]

How about this approach (for the example of deleting notes):

1. We extend our store with a temporary array/object temporaryDeletedNotes which holds the ids of the locally deleted notes
2. The deletion of a note would push the identifier of the deleted note into the array
3. The stored notes are filtered using this array: Locally deleted notes are filtered out; Child notes of locally deleted notes are mapped from {..., parent: <deleted-note-id>} to {..., parent: null}
4. After five seconds, the API request for persisting the deletion of the note would be invoked (which would trigger a note state update), and the identifier will be removed from the temporaryDeletedNotes array.

Since this array of identifiers doesn't change with state updates of our notes, we can always use it to filter/map the notes.

[SelinaBuff]

Is this discussion still current? @Schwehn42 @brandstetterm

[Schwehn42]

i'll close it as outdated for the time being, since #2350 isn't active right now. might reopen it at some point though.