Synchronizing: Part 4
Now you see me, now you don’t!
In the previous posts we talked about storing, displaying and sorting sections of a list that is a part of a realtime collaborative document.
In the final post of this mini series we are going to take a look at two important operations: creating and deleting sections.
Creating sections is relatively straightforward. There are two possible events that we need to handle:
- The data model has changed. In this case, we go through the sections in the data model and ask if there are any sections that do not exist in the view model. If there are, we add new sections to the view model.
- The view model has changed. In this case, we basically do the same thing, but in reverse.
Deleting sections can be a bit tricky, because if we actually delete them from the data model the following can happen:
- One user deletes a section locally
- The change is propagated through the realtime model to all collaborators
- Another user is editing some other section and she receives the updated data model that is missing one section.
- Both the data model and the view model are changing now, so what happens is that the deleted section gets created again out of thin air. This is because it is still in the view model, but it appears to be missing in the data model.
Obviously this barrel would no hold much water for us…
The solution is to simply mark the section as deleted instead of actually deleting it. We can do that because our data model and our view model are separated. This means that we can very easily exclude the deleted sections from the view model, making them invisible.
This produces the same result for the user, while it also simplifies the implementation significantly.
One added benefit of this approach is that we can also trigger a nice fade out animation for the sections that have just been deleted by other users, instead of having them abruptly dissapear.
That’s it folks! Thanks for reading…