Live data from Hacker News

Why you might not need MVC with React.js

code-experience.com

61–70 of 81 posts

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

#61
post #21

Earlier quoted context omitted.

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

ractive.js (which I've been using on a couple of projects) also uses a shadow DOM and learning it is shorter than this sentence.

PS. I think we both mean virtual DOM not shadow DOM.

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

#62
I still miss standalone reusable components for direct plug and play into the app.

Things like https://github.com/stevoland/react-bootstrap are not the best way of addressing this problem, I think. To use one of these components one has to plug the package in with npm, use browserify and JSX. I don't usually use npm or browserify, and write my components in pure Coffeescript, so I cannot use it easily.

We should start making all-standalone really modular React components.

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

#63
post #34

There are two problems with React which I see at the moment: 1) Layouting 2) (more to the point of this article) what if your app isn't composed as a tree? More specifically, what if I have two tightly coupled components in two different places (physically and hence in the DOM), which need to share state? I don't want to have to go through a massive tree all the way to the root just to get that information between th…

> More specifically, what if I have two tightly coupled components in two different places (physically and hence in the DOM), which need to share state?

Pass the same state to both? The application state and the render state don't have to be trivial mappings of one another.

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

#64
post #37

I've never been a fan of MVC (I've used it for both php/backbone.js and iOS). My main problem with it is that the functionality of model is obvious, view is obvious, but controller can be anything from "a model for multiple views" to some kind of delegate, to an extension of the model. I find it so nebulous that even today, I can't explain to someone with 100% confidence where the model ends and the controller begins…

it's worth reading some of the early smalltalk/MVC stuff to try to understand how MVC was originally formulated ( http://www.ics.uci.edu/~redmiles/ics227-SQ04/papers/KrasnerP... ). it can be a little hard to understand, because it's pretty significantly different from how most modern GUI toolkits work, but (as i understand it, not actually having written smalltalk code) at its core it's fairly simple: Model: business…

If you look closely in the original smalltalk definitions you'll also see that separation of view and controller was intended first and foremost as a way to swap multiple views for the same controller, assuming those views shared controls and interaction patterns. This may have made sense in the context it was designed in : rendering was closer to raw painting on a canvas, mixing event handling with painting code would probably have been ugly. In my opinion it makes much less sense in a browser where the rendering layer is almost entirely in the runtime and building UIs is pretty trivial. We all feel something is wrong because, well, something very is wrong with MVC in the client. Where to we "render" ? To the DOM. Where do user interactions come from ? From the DOM, through events. We already have the controller-view part, and it's the DOM. Everything we are doing, stated or not, is adding layers on top of it to make things simpler to manage. Glorified helpers.

Same goes for the model. If you don't like to duplicate information for the sake of it, it's pretty straightforward to note that models on the client should be ... well, are a glorified caching mechanism. All these MV* models are in my opinion strongly hindering creativity and progress.

In this respect, I think React is onto something big.

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

#65
post #56

Earlier quoted context omitted.

This is exactly the problem we've been running into building a medium sized interactive app in React. The management of data flow and state changes through the component hierarchy with callbacks can get quite complex, and you end up writing lots of callback boilerplate. So we've ended up rolling an event system that sits alongside the React components, and a lot of our app's interactivity is managed through the event…

This is exactly how react was intended to be used, and our larger apps use the flux system architecture which closely resembles what you've described. There's an example in the react repo. Om takes a different (but equally viable) approach.

Some links for folks that don't know what flux is:

https://groups.google.com/forum/#!topic/reactjs/mo0RWkg68vU

https://github.com/facebook/react/tree/master/examples/todom...

Are caches (memcached..) an obstacle in the flux architecture?

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

#66
post #56

Earlier quoted context omitted.

This is exactly the problem we've been running into building a medium sized interactive app in React. The management of data flow and state changes through the component hierarchy with callbacks can get quite complex, and you end up writing lots of callback boilerplate. So we've ended up rolling an event system that sits alongside the React components, and a lot of our app's interactivity is managed through the event…

This is exactly how react was intended to be used, and our larger apps use the flux system architecture which closely resembles what you've described. There's an example in the react repo. Om takes a different (but equally viable) approach.

Looking forward to hearing more about this.

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

#67
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…

Are most folks using ReactJS on production running NodeJS to render the first view on the server, or just server the JS and generate everything client side?

(I'm not a particular fan of JS on the server-side yet..)

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

#68
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…

I guess when your test platform is Facebook, you learn things faster.

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

#69
I really liked the article. I know that plenty of people are going to rip on it but I prefer ideas that stand out based more on individual insight than what the herd thinks (as the herd is usually wrong).

p.s. what is the platform/library used to create this website? it's nice and clean.

Post reply on HN