Synchronization on the state diff level about redux-scuttlebutt HOT 1 OPEN

Thanks for checking it out and the feedback!

Synchronising the actions themselves has a number of benefits, including

• Unrecognized actions are still compatible with outdated reducers, they simply won't have an effect on state — the application View/Renderables can't become out of sync with the state shape, since the application is responsible for them both. Local state might be different to remote state, but the app will render truthfully. We can also update the app and simply replay all known actions to update.
• Clients can always emit actions, and can always replay actions emitted by other clients, even if they happened before local client's actions. There's no way to conflict, like what might happen if two clients overwrite a common value or key in the shared store.
• With synced actions logs, shared and local actions can mutate local and shared states. Compared to store sync: Shared state changes would only be caused by shared actions, local state changes would only be caused by local actions.
  • This means you don't have to split into a local "UI" reducer and shared "posts" reducer, but can decide within a reducer which keys a public or private action affects. A relative value user.isFriend is possible, next to user.name and user.avatar.
  • Further, with redux-scuttlebutt your locally emitted actions will maintain their "correct" position in time relative to when shared actions occurred, whereas with synced stores they mustn't ever touch.

and, crucially,

• Syncing actions means your clients can be offline for seconds, or minutes, or days, and they'll still sync. Diffing store changes opens the door to conflicts, or situations where we're not sure "who came first" or "who won" when working on the same piece of data.
• Syncing actions leaves the decision of dealing with these conflicts up to the reducer, and therefore the application itself, so you can resolve conflicts any way which is appropriate.
• Also (and this is the most bizarre to explain) when multiple distributed clients are connected, your local client can exist without the latest actions from one or many remote clients having been applied. When they are eventually applied, it's as if they already happened in the past. We only have to write the one set of logic (as we do with renderable components for the views) which gives us flexibility and predictability.

I agree that the two approaches serve different use cases. State-based syncing is simpler and easier to reckon about, but hopefully bringing scuttlebutt's strengths (distributed, resilient logs) to Redux's natural structure (time-travel, statelessness and integration with React) we'll be able to raise the bar for real-time client apps.

from redux-scuttlebutt.