Flux over the Wire using Websockets and Immutable JS

I see that Remutable uses &#x27;patches&#x27;. How does it compare with ShareJS? Does it allow collaborative editing (ie multiple people changing the same data structure concurrently, is patch application commutative)?<p>The idea behind ShareJS (or OT for that matter) is awesome. You never have to think about what to do if two people edit the same document concurrently. It just works. You get undo for free. And you can write the code that it saves automatically in the background. Never again do users have to press a &#x27;save&#x27; button.<p>A while ago I wrote a library which builds on top of the same ideas as ShareJS (ie. OT) but with slightly different focus. You define object types and their properties. This allows the library to automatically parse JSON into JavaScript class instances. It also tracks changes to these objects in a very similar way as ShareJS: each change has a &#x27;path&#x27; (where something was changed) and then the actual chang record (currently set and splice).<p>I use Avers in an SPA which is an editor of fairly complex data structures (90 different object types, nested ~5 levels deep). For rendering I use React. The integration is really simple: Attach a change listener to the root and re-render when anything changes.<p><a href="https://github.com/wereHamster/avers" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;wereHamster&#x2F;avers</a> <a href="https://caurea.org/2015/02/08/the-future-of-avers.html" rel="nofollow">https:&#x2F;&#x2F;caurea.org&#x2F;2015&#x2F;02&#x2F;08&#x2F;the-future-of-avers.html</a>

Hmm, I don&#x27;t really get it yet, but &quot;single source of truth&quot; sounds to me like it needs extra round-trips to this &quot;source of truth&quot; in order to update the display (even if the updates come from the client itself). Is that correct?

Alas, I&#x27;ve been working on something like this for the last few weeks on and off, especially the &quot;patching&quot; of immutable data, my solution was to use jiff[1], which generates JSON Patch operations[2], which is then applied to the Immutable object using immpatch[3] (a lib I wrote).<p>A cursory look at Remutable seems it to be the better and faster option :)<p>[1] <a href="https://github.com/cujojs/jiff" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cujojs&#x2F;jiff</a><p>[2] <a href="https://tools.ietf.org/html/rfc6902" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc6902</a><p>[3] <a href="https://github.com/zaim/immpatch" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;zaim&#x2F;immpatch</a><p>(edited formatting)

Remutable looks really impressive. I&#x27;m a little leery of the rest of it, though, as it means my backend is no longer a simple REST API. I&#x27;m also rather nonplussed that the full-stack Flux doesn&#x27;t include optimistic display with loading icon, error state, and rollback handling out of the box. It doesn&#x27;t even seem like an easy thing to do manually with this setup, though I haven&#x27;t played with it enough to know.<p>Few minor questions: it looks like a base Remutable must be an Immutable.Map(). Can child items be any of the Immutable datatypes? Do we get updateIn() and similar?

&gt; We will rather record the mutations (or more accurately, the transitions between immutable states), and just replay them on the client.<p>Few questions -<p>How can we replay all the mutations?<p>How about instead of replaying, if we just show the last mutation? Will it not be the same thing?<p>I think this flux architecture will work best only in chatting applications. This approach is also making the app itself very chatter so performance concerns in case you do not have strong machines.<p>I think on form pages this flux approach may not be required.

Wow, a crashed site presenting a web architecture surely isn&#x27;t classy! Sorry about that, I&#x27;m working on it.

The best example of single source of truth may be chat, but I believe chat is the best example of a replicated log. This throw me off a bit while reading the article :| Left it, came back to the comments later to see people talking about OT and realized I missed something. Just an obesevation.

Synchronising state over the wire? Surely this is a solved problem in games development already - serialise your state into a consistent binary form, send over the binary diff of the previous state (AKA delta compression), deserialise on client side.

Take a look at swarm.js for a fantastic way to keep stores in sync - even works in offline. Matrix.io could also be an interesting option for this, but focuses more on communication than shared data.

The single source of truth diagram is so great! :) Was getting tired of turning my head sideways..

cache: <a href="http://webcache.googleusercontent.com/search?q=cache:http://blog.rotenberg.io/flux-over-the-wire-3/" rel="nofollow">http:&#x2F;&#x2F;webcache.googleusercontent.com&#x2F;search?q=cache:http:&#x2F;&#x2F;...</a>

slightly offtopic question; what are all those `should.be.exactly(whatever)` calls in the Remutable readme?