4 ms·

That's a really informative tutorial series. A tip to everyone checking the codebase (JS parts) to learn about building a Trello-like application, there isn't

That's a really informative tutorial series. A tip to everyone checking the codebase (JS parts) to learn about building a Trello-like application, there isn't any optimistic UI updates in this tutorial app. (eg. after dragging a card to another list, displaying the card at the dragged position before receiving confirmation from the server.) When you add optimistic updates to the mix with real time updates, things get much more complicated. Tracking pending updates, rolling back when something goes wrong, ordering of updates, reconciliation with server when the client is missing some updates etc. I'm building something similar, and these have been most time consuming parts to build in a reliable way.

tomjen3 11y ago
Thats one of the really nice things about react: you can update the state on the clients copy of the board data, let react change the UI as required, then let the server send over the new state once it has one, update the clients state as required and let react deal with the ui updates. As for reconcillation I would probably just have the server send over the entire current state of the board when the client connects. It is much easier and doesn't waste that much bandwidth, which is cheap anyhow. Am I missing something?
- hakanderyal 11y ago
  The 'happy path' (everything goes right) is easy, as you said. The hard part for me was making sure the state in the client is always in sync with server, in a valid state, even when things go wrong. On a slow connection, another update made by someone else to board may arrive between the optimistic client update and the server confirmation, which can lead to a broken state on client. Or, user may do an update on the optimistically added card, like editing, while the first action is not confirmed by the server yet. You either need to queue these actions, or generate the id of the card on client side. And you need to have reliable 'rollbacks' on the client when server rejects the action for some reason. There are many more edge cases like that. I've solved all these problems eventually, but it took much more time for me than building the happy path.
  - eric_bullington 11y ago
    > And you need to have reliable 'rollbacks' on the client when server rejects the action for some reason....'ve solved all these problems eventually, but it took much more time for me than building the happy path. I'm sure you figured this out, but having an immutable data structure at the root of your React application is great for rollbacks. And then maintain an array with a reference to the various data structures, however deep you need (within reason), and pop or push them as needed to rollback/roll forward.
    - hakanderyal 11y ago
      Yes, I'm using Redux, and never modify the state. But I also needed to rollback only the rejected action, and keep the rest of the actions that user did after the rejected action intact. That presented a whole lot of different edge cases. I created a solution based on redux-optimist[1], modified to my apps specific needs. [1]: https://github.com/ForbesLindesay/redux-optimist https://github.com/ForbesLindesay/redux-optimist

tomjen3 11y ago

Thats one of the really nice things about react: you can update the state on the clients copy of the board data, let react change the UI as required, then let the server send over the new state once it has one, update the clients state as required and let react deal with the ui updates. As for reconcillation I would probably just have the server send over the entire current state of the board when the client connects. It is much easier and doesn't waste that much bandwidth, which is cheap anyhow. Am I missing something?

hakanderyal 11y ago
The 'happy path' (everything goes right) is easy, as you said. The hard part for me was making sure the state in the client is always in sync with server, in a valid state, even when things go wrong. On a slow connection, another update made by someone else to board may arrive between the optimistic client update and the server confirmation, which can lead to a broken state on client. Or, user may do an update on the optimistically added card, like editing, while the first action is not confirmed by the server yet. You either need to queue these actions, or generate the id of the card on client side. And you need to have reliable 'rollbacks' on the client when server rejects the action for some reason. There are many more edge cases like that. I've solved all these problems eventually, but it took much more time for me than building the happy path.
- eric_bullington 11y ago
  > And you need to have reliable 'rollbacks' on the client when server rejects the action for some reason....'ve solved all these problems eventually, but it took much more time for me than building the happy path. I'm sure you figured this out, but having an immutable data structure at the root of your React application is great for rollbacks. And then maintain an array with a reference to the various data structures, however deep you need (within reason), and pop or push them as needed to rollback/roll forward.
  - hakanderyal 11y ago
    Yes, I'm using Redux, and never modify the state. But I also needed to rollback only the rejected action, and keep the rest of the actions that user did after the rejected action intact. That presented a whole lot of different edge cases. I created a solution based on redux-optimist[1], modified to my apps specific needs. [1]: https://github.com/ForbesLindesay/redux-optimist https://github.com/ForbesLindesay/redux-optimist