Skip to content

Single point of server calls & git rebase app state

Petter Eriksson edited this page Dec 6, 2017 · 6 revisions

A non-obvious benefit of om.next is that all requests is called from a single function and responses is merged in another. This enabled us to think about remote resources and their effect to state transitions in a new way.

  • We can control which and how many remote calls are in-flight
  • We can know what the user has done while remote calls are in-flight
  • We have references to different versions in the app-state (because of immutability).

What's a way to optimistically update state, pull from a source of truth and handle conflicts? Git does this (ish). Given the properties described above, we can implement git-rebase. We did. It's pretty neat.

Optimistic updates made easy

Having an automatic git-rebase-like state transition for remote responses makes it easy to implement optimistic updates. Whenever the user is about to make an action, we set aside a reference of the current version of the app-state so that we know what the state was before the action. We can apply the optimistic update to the app-state, and whenever the remote response is returned, we reset the app-state to the point before the optimistic update before applying the remote response. If there has occurred other optimistic updates, they are re-applied (by running the actions again) to the app-state while they wait for their remote responses.

Here's the down side. Because all optimistic updates has to be applied in the same order they we're applied originally, we only send one request at a time, incase we have to re-send requests. This trade off has been ok for us since requests group together mutations and reads.

It's also very easy to fake the requests when they're all in one function, making it easy to test our code in different ways. See our page on Full Stack Testing

Code where we implemented the send function with "git rebase" like functionality:

eponai.client.backend