Why you might not need MVC with React.js
code-experience.com
Why you might not need MVC with React.js
1–10 of 81 posts
Re: Why you might not need MVC with React.js
#2Thanks for this article. When I started playing with React (and seriously, I'm just playing right now), it felt to me like the whole MVC concept wasn't necessary, because I could just move state changes around to the correct places via the virtual DOM. But I'm not a front end guy at heart. I don't have the deep knowledge that the world of MVC masters do.
I have a rule of thumb that when I find myself disagreeing with people I consider smarter and more experienced than me, I question my assumptions before questioning the experts. It doesn't mean I always bow to them, but I don't assume I am right because I'm so dang smart, even if that's the case much of the time. :) So when I find myself questioning the very necessity of a full MVC framework within the context of a React-powered application, I felt I should just withhold judgment for a while.
This article by someone much more experienced than me lays out what I was feeling instinctively. Excellent.
Re: Why you might not need MVC with React.js
#3I've been doing a broad survey of these JavaScript frameworks for a month or so now. I've looked primarily at Ember, Angular, React, and Knockout. One thing is for sure: React has the community that feels the most "enlightened." I've watched several videos and read several posts similar to this one that express this sentiment of "when I finally understood it, it just clicked, and now I realize it's the best thing in the world." That excitement is certainly infectious, although I find myself wanting to hear "the other side of the story" from someone who dislikes React.
Re: Why you might not need MVC with React.js
#4I think this is a misrepresentation of what makes React.js valuable. React is useful for optimizing your rendering (model state -> DOM state) because you don't have to think about re-rendering sub-views of things that haven't changed. This has nothing to do with defining a communication flow for your app. You're still propagating state up and down your tree whether it is a tree of Backbone views or React components.
Rendering optimization is definitely a nice thing to not have to think about though.
Re: Why you might not need MVC with React.js
#5If you want a mostly pure DOM-based framework, take a look at Polymer, too (http://www.polymer-project.org/). Web components seem to really embody what the article is driving at.
Re: Why you might not need MVC with React.js
#6Some code samples would be nice to really demonstrate what the article states. Conceptually I don't see much of a difference from what knockout and other data-binding libraries did in the past, or even an event-based system; React's breakthrough is really the virtual DOM and template system.
Re: Why you might not need MVC with React.js
#7If you want a mostly pure DOM-based framework, take a look at Polymer, too ( http://www.polymer-project.org/ ). Web components seem to really embody what the article is driving at.
Isn't React a mostly pure DOM-based framework as well?
Re: Why you might not need MVC with React.js
#8Some code samples would be nice to really demonstrate what the article states. Conceptually I don't see much of a difference from what knockout and other data-binding libraries did in the past, or even an event-based system; React's breakthrough is really the virtual DOM and template system.
Imagine multiple nodes. In order to communicate between them, they need some kind of connection, this is coupling. When you have too many connections the application is hard to maintain and extend. The connections are all on the same layer, therefore is too confusing.
Now think of a tree. Now imagine the nodes being some points on the branches on the tree. If one node want to communicate with another, it has to go down to the joint node and then go up to the target node. This will increase the indirection (and of course is less performant), you will have to pass data (and callbacks) between components but there are no global connections. In this way you make your application easier to edit and is less coupled.
Hope you understood something (: maybe I will write a post with some images on my blog ;)
Re: Why you might not need MVC with React.js
#9Well you need a router and a way to persist data.Does React offer this?
How do I manage page changes with React?
React only concern is the view afaik. An app is more than a view,even in the client.
So react is not MVC,but you still need MVC somewhere.unless you write one page apps of reactive documents.
> It does not define how communication flows.
I think it does ,in pure MVC:
- view is stateless,view is 100% model driven.
- controller gets events.
- controller modifies the model.
- model notifies the view to update.
Of course that is in theory. In practice the view has states.
The difficulty of "pure" MVC is that the model doesnt represent some data from the server or whatever, but the states of the view.
The other problem is,in the browser,obviously the DOM has states. That's why MVC is not good for front-end dev,since it negates how the DOM works.
Virtual DOMs are better as they embrace how the DOM works. And yes the DOM is a tree.Trying to reproduce a tree with Backbone views and underscore template is madness.
Let's remember that MVC is a really old pattern ,created in a time where UIs were coded quite differently.
Re: Why you might not need MVC with React.js
#10I think this is a misrepresentation of what makes React.js valuable. React is useful for optimizing your rendering (model state -> DOM state) because you don't have to think about re-rendering sub-views of things that haven't changed. This has nothing to do with defining a communication flow for your app. You're still propagating state up and down your tree whether it is a tree of Backbone views or React components.…
What do you mean? Child components don't pass their state to parent components. It's what allows React to be declarative. It's right on the front page:
"React implements one-way reactive data flow which reduces boilerplate and is easier to reason about than traditional data binding."