3 ms·

Why not just have MVC for the page, and MVC for components? Each component would render itself. I personally think that this requires a lot of machinery under

Why not just have MVC for the page, and MVC for components? Each component would render itself. I personally think that this requires a lot of machinery under the hood, such as caching and batching requests (since no one knows ahead of time what components will need to be rendered). At least that's what we built in our Qbix Platform (http://platform.qbix.com http://platform.qbix.com). Reusable components you just place on a page and they "just work". Unlike React, etc. they support more than just re-rendering. You can of course have a virtual DOM (via a lib like Mithril or https://github.com/Matt-Esch/virtual-dom https://github.com/Matt-Esch/virtual-dom etc.) but it would be nice to handle other kinds of events besides just "re-rendering".

emidln 11y ago
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.
- ac2u 11y ago
  The data dependencies mapping part sounds a little bit like FB's relay proposal https://facebook.github.io/react/blog/2015/02/20/introducing-relay-and-graphql.html https://facebook.github.io/react/blog/2015/02/20/introducing...
  - emidln 11y ago
    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.
- Hansi 11y ago
  Any good pointers on reading material for architecturing something like this? Would be interested in more details.
colinramsay 11y ago
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-development-blueprints https://www.packtpub.com/web-development/ext-js-application-...
- derefr 11y ago
  Seaside (http://www.seaside.st/ 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.
  - muraiki 11y ago
    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/ http://deepintopharo.com/
emehrkay 11y ago
Is this the same as Hierarchical MVC (http://en.wikipedia.org/wiki/Hierarchical_model–view–controller http://en.wikipedia.org/wiki/Hierarchical_model–view–control...) ?

emidln 11y ago

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.

ac2u 11y ago
The data dependencies mapping part sounds a little bit like FB's relay proposal https://facebook.github.io/react/blog/2015/02/20/introducing-relay-and-graphql.html https://facebook.github.io/react/blog/2015/02/20/introducing...
- emidln 11y ago
  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.
Hansi 11y ago
Any good pointers on reading material for architecturing something like this? Would be interested in more details.

colinramsay 11y ago

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-development-blueprints https://www.packtpub.com/web-development/ext-js-application-...

derefr 11y ago
Seaside (http://www.seaside.st/ 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.
- muraiki 11y ago
  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/ http://deepintopharo.com/

emehrkay 11y ago

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