m-reza-rahman
Is there a particular reason for conservative manipulation of the Todo list?
In all operations on the list (save, remove etc.), the changes are first made in the backend and then cascaded over to the client side. Is this sequence followed to keep the client side complexity simple?
In contrast, we could first show the changes (and make it feel like a snappier application, like Facebook's comment system) on the client and then propagate them to the backend. I understand that the negative scenarios can lead to some additional code/complexity in this case.
(I'll try to send a PR for the alternative implementation, if need be).
Avoiding additional complexity in writing failure handling code is the primary reason. I don't want beginners to get the impression that this architecture is difficult to develop and maintain. As such, I think the user experience is also already fine.
That said, feel free to fork the repo and create and alternate, more responsive version? Do you need anything from me for that? If so, just ask and I will set you up with what you need? I'll be happy to highlight the fork.
