Hacker News new | past | comments | ask | show | jobs | submit login

Well, this is exactly the goal of this pattern.

One thing I didn't mention is that I use MVC per component, not for the full application. (I use something else for the global Application level).

So, every major component has its own MVC. I.e. One page on mobile listing a items with a bunch of interaction would have its own MVC.

And why it's robust and efficient:

Very easy to reason about the data and write unit tests. The whole data is in the State, and only the controller can alter that state.

The view is completely decoupled because it can't change the state, it can only declaratively render something (we use React with immutable). And this is also very easy to test and mock with fake data.

As for performance, I've tried various strategies over the past few years, and I find Immutable data structure + virtual Dom pretty damn amazing. I personally use React.js + Immutable.js, mostly for the great documentation but this is definitely not the only libraries.

And if the view becomes that much more complex, then it's time to spawn a new component with its own MVC.




I don't think that works well if the view is a complex function of the state. You can break the MVC into smaller components with an inner state, but how do you know which components to update when the outer state is updated? I believe you can't know, unless you duplicate the complexity of the smaller components into your larger component.


From what I understand, react + redux has a couple of tricks up it's sleeve.

As the components don't hold state, only display the state of the model (part of the redux store state), components only need to be re-rendered if the state has changed.

If you combine this with reselect (https://github.com/reactjs/reselect), then this allows you to only re-render components when the sub-set of the state tree is changed that can affect your component.

So to a certain extent you're registering your component's interest in a sub-set of the state, and then only re-rendering when that sub-section changes. The trick is then to ensure that as you build your app you don't build a single component that depends on everything and pass state down as props, but lots of smaller components that depend on a small sub-set of the tree.


Does that also work if the dependence on the state tree is not hierarchical? I.e., subcomponents referencing the state in a random-access way?


It would be much easier if you provided an example of what you have in mind. The approach I mentioned work perfectly for us, but it doesn't mean it'd work for you.

But to answer your question, it shouldn't matter if subcomponents reference the state in a random-access way. Our workflow is like this:

a) Main components fetch data from an external module. (That module either queries the server, gets the data from the client database or uses something already in the memory cache).

b) That main component generates a ModelView state. Basically, it transforms the fetched data into something it can use. It could mean joining models together, etc.

c) The view uses the ModelView state to render itself. Each component generates a virtual dom representation and then renders themselves in the DOM.

d) Now, there are two different ways this ModelView state can be altered:

  1) From a global event (eg. New changes came from the server. Or a component elsewhere in the app sent a global event.)

  2) From the component itself (eg. An event/action is sent from the view)
e) Either way, once that ModelView state has changed because of that event, the view gets re-generated very efficiently. I.e. Only the small part that visually change gets rendered.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: