Simpler UI Reasoning with Unidirectional Dataflow and Immutable Data

I&#x27;m glad to see more people writing about functional programming for JavaScript web applications. I liked a lot of the ideas here, but I don&#x27;t really see the need for the &quot;component&quot; data type. Why not just regular functions? Also, I don&#x27;t think that letting each component determine whether or not it needs to redraw is a good idea. I&#x27;d rather just let the rendering system handle it by diffing the tree. With immutable data, it&#x27;s trivial to see if a node has changed and redraw the subtree.<p>I&#x27;ve been doing experiments with Mithril (provides virtual DOM) and various functional reactive programming libraries (such as Kefir), and I think something like that is the right way to go.

I evaluated this, and wrote some code in it, but ended up choosing nuclear-js as my react framework. Has many of the same concepts, but within the flux paradigm, and has the awesome concept of getters. Getters are a combination of several keypaths into the immutable app state, plus an optional transform function.<p>Also, nuclear seems quite stable at this point, and the GitHub issues are about pretty practical stuff, while omniscient has had very recent breaking API changes and many of the issues are discussions about functional purity etc. Just my two cents on why I chose one over the other.

This topic is also covered in the talk from JSConf Budapest: &quot;Functional UI and Unidirectional Dataflow&quot;: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=JNMWi7Z0Ssg" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=JNMWi7Z0Ssg</a>

I really like the Om&#x2F;Omniscient model of using immutable data to represent application state - deciding whether or not to rerender a component and all of its subcomponents only requires comparing a hash.<p>However, for the app I&#x27;m working on, I want most the single source of truth for most application state to be on the server. I&#x27;m passing data from server to client in JSON. Has anybody come up with a good way to serialize&#x2F;deserialize immutable objects? I might try out transit-js, but I&#x27;m wondering if anybody has already gotten this working?

A bit of a tangent:<p>I have been experimenting with replacing REST style backend interaction with websockets an having the state manipulation round-tripping through the server.<p>Instead of setting values on mutable objects and telling the server about it postfact (having to deal with errors like ba validation and connectivity somehow), I would send a change command to the server, which would decide what to do, and push an updated state back. Once I detect this change of state, I update the UI.<p>This simplifies error handling a lot, since the user simply can&#x27;t update state if an error occurs. And I get cuncurrent multi user editing for free.<p>Unless you want offline editing (which is <i>hard</i>), it&#x27;s a big win.

Unidirectional dataflow is nice, but how do you figure out what parts need updating? And is all the bookkeeping necessary to figure that out not expensive?