When I built this a couple companies ago for a charting/dashboarding app, we used components simply had channels to receive events and send events. When a component was to be loaded, it provided a map of its data dependencies so that we could ensure efficient batching and appropriately updated queries. Unloading was resolving that in reverse. Clojurescript + core.async and some macros made this very very easy to implement, use, and extend, but you could easily do it on top of whatever random messaging system and virtual-dom you wanted.

In my app's scenario, we made a render decision based on the input and output for the component render functions. Prior to rendering the view, if the data was identical to what already existed, no updates occurred. cljs made this cheap. After constructing the template (hiccup-style, more cljs data), if it wasn't different, we'd also skip the DOM update.

For methods on the component (handling various events and such), they all take a channel where they could send whatever events it was that they needed to send.

The data service managing a query for one or more components just blocked its goroutine until it received an update to its query data structure, resolved it, and if it was different than the existing query data structure, would debounce for more changes before sending off the request. Requests back to the server were ordered by an atomic counter (atom 0) such that out of order responses could be processed sanely. Everything was one-way.

Additionally, while we could dynamically render everything, pages were a layout data structure containing 0 or more components with associated data services. These were all described in EDN and thus could be serialized, queried, and rendered server side if necessary.

All of this machinery was pretty small, no more than about 1800 LOC building on top of some excellent cljs libraries.

The data dependencies mapping part sounds a little bit like FB's relay proposal https://facebook.github.io/react/blog/2015/02/20/introducing...

Yes. We had a query language that let us string together AND/OR/NOT filters as a tree and then the backend could decompose and query off of it. We'd have a data service per document type being queried. In our situation, customer feedback aggregates, vertical aggregates and customer feedback datums were different. So a page containing components using both would necessarily have two data services working independently.

Any good pointers on reading material for architecturing something like this? Would be interested in more details.

I did some research into MVC a few months ago for a book [1] and my understanding is that this is how it worked when the concept was first devised in those first few Smalltalk releases: something like a textbox would still have the M and the V and the C. React just feels like a simplified version of that to me.

https://www.packtpub.com/web-development/ext-js-application-...

Seaside (http://www.seaside.st/), the Smalltalk web-application framework, does exactly what you're talking about—each component on the page has its own server-side view-controller, much like if you were using a controls library in a native GUI app.

One should also note that Seaside is likely the direct inspiration for Arc's (i.e. HN's) use of links that reference stored server-side closures by ID.

The free Seaside book and also the free Pharo by Example book are great ways to learn MVC. The only downside is that after using Seaside and a Smalltalk environment, you will probably be dissatisfied with not having such awesome features available in modern tools. :)

Edit: It looks like there is a new Pharo book that covers more advanced topics! http://deepintopharo.com/

Is this the same as Hierarchical MVC (http://en.wikipedia.org/wiki/Hierarchical_model–view–control...) ?