Why you might not need MVC with React.js

I wonder how true that will be given the simplicity of React. Ember and Angular and so big that it takes that long to find the things you don't like. Having said that, I like angular and react in very different ways.

I don't know, I think the excitement around angular was because it made things easy, while the excitement around react is based on its simplicity of its model. It's a deeper thing than just being a shiny new thing imo.

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.

> With React, I don't really see the point of Ember or Angular

React only deals with the view. In AngularJS, third party objects have a seamless integration with the view.

Imagine you want to paginate datas.

You'd write a Paginator component in React.

In Angular you'd have a Paginator service holding pagination logic. Then you can have multiple representations of paginators,that would be logic less. It's better because it makes it easier to test the pagination logic in isolation,and you can then hide some complexity out of the view.

i did it with a simple notification queue in a project i'm working on :

		.service('Notification', function($timeout, NOTIFICATION_TIME) {
			/**
			 * manage notifications
			 */
			var onNotificationTimeEnd ;
			this.type = {
				'SUCCESS': 'text-success',
				'ERROR': 'text-error',
				'INFO': 'text-info'
			};
			this.timeout = null;
			this.current = null;
			this.notifications=[];
			/**
			 * queue app notifications
			 * @param  {Object} notif
			 */
			this.notify = function(notif) {
				if(notif){
					this.notifications.push(notif);
				}
				if(!this.current){
					this.current = this.notifications.pop();
				}
				if(!this.timeout){
					this.timeout=$timeout(onNotificationTimeEnd.bind(this), NOTIFICATION_TIME);					
				}
			};
			onNotificationTimeEnd = function(){
				this.current=null;
				this.timeout=null;
				if(this.notifications.length>0){
					this.notify();
				}
			};
			
		});

So each time a new notification pops , the view is updated just by adding {{Notification.current}} somewhere in my template

I think React solve parts of the problem while Angular tries to solve the whole problem.

I think there is definetly a middle ground between AngularJS and React virtual DOM that can be found. Let's remember that Misko defines AngularJS as "a better browser",not a framework.

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

Your comparison makes no sense. React isn't really competing with something like Ember -- the more direct comparison would be React vs HTMLBars (the low level view layer library being used in next generation Ember).

Even if I choose react for my view layer, I'm still going to need infrastructure for managing application state. View layer concerns are probably less than 30% of what I get out of Ember. The rest is bidirectional routing between URLs and models, meaningful controller hierarchies, etc.

React is simple because it ignores all that. But any significant app will still need to deal with those things.

The app the blog is based on is actually implemented in chaplinJS in production. It is a big improvement over Backbone, but it doesn't have the conceptual clarity of React. I actually moved to React because I was not satisfied with the chaplin solution.

Do you have an opinion on blending it with other MV* frameworks, and what works well? I was originally thinking Angular for this work, but I liked working with React so much... would React integrate better into Angular, or Backbone, or something else?

Again, not much of a front end guy. Last time I did serious front end was several years ago, when I spent 3 months coding in Sencha (and arguing with sloppy coders who liked the pretty Sencha widgets but didn't see the value of using the MVC pattern, grrr).

I just want to be able to build a nice, modern front end with minimal grief, learning curve, or dogma. Is that so much to ask?

I called it a best practice because:

a) It's in their official tutorial: http://facebook.github.io/react/docs/tutorial.html#callbacks... , and

b) My friends who turned me on to React (as well as the StackOverflow that came up after a quick Googling) confirmed that you aren't supposed to create custom events in React, and should instead follow the callbacks-as-props model.

If I've misunderstood something, I'd love to know the better way.

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.

You can also use something like react-router-component which integrates very easily with React:

https://github.com/andreypopp/react-router-component

The devs that created React are using React + Backbone.Router for Instagram's desktop site.

It's very easy to integrate Backbone.Router into a project.

Please do finish the post, this is a hard problem.

I'm using the exact same flow in my current project.

Shared data is stored in the state of a single component. Data propagates via props and since you've got a single source of truth you don't have to worry about data synchronization. To manipulate data, the component that owns the data exposes methods to children via context.

As a bonus, components become incredibly easy to test since both props and context are both explicitly passed to each component.

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"

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.

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:

    <roster-list persons='[{"name": "John"}, {"name": "Bob"}]'></roster-list>

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

Not really: a lot of its value is in the fact that the DOM gets abstracted away as "just another render target" (canvas, and perhaps even eventually native UI's could be potential future targets)

React can fully render out to a string of HTML without any dependencies on a DOM implementation (for instance, if you're on the server)

(http://facebook.github.io/react/docs/top-level-api.html#reac...)

i am not sure why this is downvoted. I also find model to be the easiest to wrap my head around. At one my pervious jobs we took the 'model' out of a desktop app and put a web front on it.

My $00.02 on MVC…

It's very interesting to see younger programmers speaking up these days. (No condescension intended; it just feels weird to be entering that old guy stage now, with 15 years of hardcore web/mobile application development experience) These younger guys are very, very sharp with enormous amounts of very cutting edge knowledge about current and quite advanced technologies. No doubt from the enhanced participation/availability model of example code the internet has undergone in the past 6-8 years (really since its inception, maybe it is just wider used now).

I think the keys to MVC for me are the logical silos by type. I don’t remember who first used the term ‘tier’ in this context, but I remember it back in 2000, possibly sooner with RUP to describe a multitier/n-tier application. This was a time of great debate online about the separation of concerns like data and security contracts of the newly developing web services… It had been mostly Cobra, DCOM and EJB’s up until this point. But I digress…

A very basic N-Tier architecture could be looked at like this:

Data Tier: This was the area that the core data logic and rules around the domain specific knowledge were guarded--and different from all aspects of the system. Like a phone company and their telephone number, as well as the number of minutes a particular telephone number is allowed, have specific requirements. The Data Model is where those types of requirements and rules are implemented.

Business Tier: Things like a father setting up time walled minutes on his daughter's phone so she can't talk on the phone at night... The data model would not allow even the business logic to set a negative number on the minutes; it would allow configuration of those domain model fields within proper bounds.

Presentation Tier: To make it easier on the user, we'll make the data entry screen telephone field on our external application format the input number to our specific carrier’s style: xxx-xxx-xxxx. The Business logic would handle events raised by the presentation tier and return a success message or possibly a failure message triggered from the business silo where the father hasn't paid his bill so the family management aspect of the program will not work until he does. Today, this will most probably be a JavaScript app responding to an asynchronous message from an open source web socket server, but it used to be good old request/response.

There’s all manner of debate as to missing tiers, level of complexity per tier or any manner of versions of good architecture. I've heard the database referred to as the Data Tier, when it was obvious the domain model rules require far more granularity and limitations than a simple database could provide.

However, from the above tiers, I think you can see where a M C V architecture begins to emerge from this separation of logic by the type of requirement it falls under. Why it’s ordered: MVC always boggled me—but I’m sure Fowler (aka Captain Obvious) could give us a reason.

The idea did not develop, IMO, from a need to over complicate a simple task, but rather from the large scale factory production mentality of early software shops. If you have the money for 20 developers for a very large project how can you separate their tasks by skill or experience so all their work will be countable like beans? Large engineering processes and tiered architectures, Business Analysts and Data Analysts, and even Architects and Silver tongued CEOs.

This was one of the uses of the whole front-end v/s back-end developer. I think this was a P.C. way of asking if you were an over glorified graphic designer with scripting skills or tier-minded.

Object oriented programming became appealing to some because with highly decoupled separation of concerns and fewer logical endpoints, abstractions could be applied. Every ‘Controller’ could extend an abstract class which could bake in the functionality to log all requests and responses for auditing purposes. You could abstract the data tier so its server load could be managed independently. You could even abstract the logic of the business rules into a new language which could be the savior or large enterprise wide service deployments: BPEL and ESBs.

Let me wrap up: In my opinion: MVC or MV* is a school of thought that has good use when one thinks in the context of the logical grouping of functionality by requirements and their type, with the ability to extend those types individually with functionality across their tier. 

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.

Get off my lawn.

The connections are not all on the same layer in Knockout. It does not seem like you have ever used it? It uses a hierarchy/tree of binding contexts. For dependent values you have a computed binding which creates an implicit dependency which triggers a change whenever it's dependency changes. It works very well in my experience.