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.
Why you might not need MVC with React.js
61–70 of 81 posts
Re: Why you might not need MVC with React.js
#62Things 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
#63There 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…
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
#64I'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…
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
#65Earlier 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.
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
#66Earlier 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.
Re: Why you might not need MVC with React.js
#67I'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…
(I'm not a particular fan of JS on the server-side yet..)
Re: Why you might not need MVC with React.js
#68I'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…
Re: Why you might not need MVC with React.js
#69p.s. what is the platform/library used to create this website? it's nice and clean.