Live data from Hacker News

Why you might not need MVC with React.js

code-experience.com

11–20 of 81 posts

Re: Why you might not need MVC with React.js

#11
post #4

I 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."

I think when he said "propogating" he was simplifying, "use props to propogate state down the tree and use callbacks to propogate/change state further up the tree"

Re: Why you might not need MVC with React.js

#12
post #9

Well 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…

React doesn't offer routing. The React TodoMVC implementation uses Director, a separate library for routing: https://github.com/tastejs/todomvc/tree/gh-pages/architectur...

Re: Why you might not need MVC with React.js

#14
post #7
post #5

If 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?

As far as I've been able to tell, React and Polymer basically address the same problem. (And, unfortunately, each community is said to be dismissive of the other. So there's that.)

My personal take is that, unless Polymer gets integrated into the browser, React is a better solution because it doesn't try to do custom DOM elements.

Re: Why you might not need MVC with React.js

#15
post #3

I'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…

That has less to do with React specifically, and more to do with how languages/tools/libraries generally gain adoption. React is at a point where there's still an emerging "early-adopter" community. Angular was like that a year ago (I distinctly recall the tone on HN to be similar to your impression of the current sentiment around React). Now Angular is starting to reach the mainstream (loosely defined), which means that now there is a trend of people pointing out flaws in Angular.

Give it a year or so.

Re: Why you might not need MVC with React.js

#17

Earlier quoted context omitted.

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."

I think when he said "propogating" he was simplifying, "use props to propogate state down the tree and use callbacks to propogate/change state further up the tree"

Even if that's a quote from the site, I still think it's just trying to explain what React is doing in a more digestible way. Any state belongs to one component. The extend of any "propagation" is invoking some function you've been given by your parent.

Re: Why you might not need MVC with React.js

#18
post #7
post #5

If 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?

it is. one difference i think is that polymer seems to rely on Web Components API and shadow DOM. i guess subviews in React are functionally identical, but React does so without regard for the Web Components API. which has been fine with me.

personally, i don't like seeing stuff like this in Polymer:

    
and i like that React let's you write views without data-as-strings.

Re: Why you might not need MVC with React.js

#19
post #3

I'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…

> "when I finally understood it, it just clicked, and now I realize it's the best thing in the world."

There's very little to understand, it's really really simple.

With React, I don't really see the point of Ember or Angular, they're basically zombie projects now. I wonder how their devs feel about React. React is an evolutionary leap enabled by their shadow DOM technology. Being able to rerender the whole page in a millisecond is a game changer.

Re: Why you might not need MVC with React.js

#20
post #9

Well 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…

> So react is not MVC,but you still need MVC somewhere.unless you write one page apps of reactive documents. In that case I think ractive is easier to use than react.

i think MVC is defined without regard for the number or pages or how said pages might be routed. you don't "need MVC somewhere".

Post reply on HN