DEV Community

Discussion on: What is the standard way to keep UI state and backend state synced during updates? (React and Node)

Collapse
 
avalander profile image
Avalander • Edited

I'm afraid there is no universal answer. All your ideas are potentially good solutions, depending on the particular idiosyncrasies of your app.

On my server PUT/POST route handler, i could return items array, including the one updated.

As you say, the good thing about this is that your backend is the indisputable source of truth and you get the entire current state after an update operation. This might be desirable if you expect multiple users to update the array of items concurrently and it is important that the users don't see stale data. The other advantage is that you need to do less work on the client side. The client can just discard the previous state after an update operation, instead of having to merge the update result with the previous state.

However, the larger your array gets, the less practical this approach becomes. Also, if it is really important to keep the state updated in real time, this approach by itself is not enough.

On my server Put/POST route handler, i could return only updated item.

I'd say this is quite standard strategy.

I don't know a lot about React, but isn't it supposed to take care of only updating the UI nodes that have actually changed when you update the state? This depends a lot on how you are managing your state, but even if you need to set a new array to the state of the component, I don't think there's a huge computational cost involved.

On my server Put/POST route handler, i could return a status code/message to signal UI that operation succeeded and now I can update UI state.

I don't see any advantage in this solution over the previous one. That is, unless the payload you are sending to the server is huge and you need to cut down bandwidth usage, but I'd say that's very unlikely the case.

The advantage of getting the updated item back from the server is that you get any transformation that the server might have performed on the item.

On UI side, I do the update first, then send the updates to backend.

I've seen some applications that do that. I personally think it is bad user experience to act as if something has been updated and then show an error saying that "yeah, it didn't actually go through, sorry about that". I'd rather just have some feedback that the operation is in progress and see the updated state once it has succeeded

This is just my personal opinion, though, if you think this will enhance your user experience, is as valid as any other option. I can see it as a valid approach in an app that behaves synchronously and uses a remote server to back up data, but doesn't depend on it. In that scenario you might even implement a retry system and only cascade the error to the UI when something goes really wrong.

Collapse
 
arpitrathi profile image
Arpit Rathi

Regarding the last approach about updating UI first and showing loading screen and then show if database operation succeeds and revert if database operation fails seems kinda like extra state management and unnecessary tricky rollback work.

A better approach to the last one could be just start updating backend, show a loading scren while thats happening and if it succeeds just do a UI state update.
This will save us from the work of rollback in cases of backend fails

Collapse
 
lennythedev profile image
Lenmor Ld

Thanks for the very detailed response
At this point, the project is in its early stages, and all of these ideas will definitely help me plan the project better