Why you might not need MVC with React.js

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. 

I've never heard the 'pass callbacks to descendants to modify state' considered as a best practice, but I don't think that's bad either. It's a tool in the tool box. But it's not more of a best practice than other tools.

DOM Event bubbling is pretty great, as it enables e.g. decorator patterns without having to replicate bubbling through your own EventEmitter system.

But once you're passing a multiple callbacks down to all children, it's just tedious. It may be better to just pass a complex object (not a function) to your children.

Tangibly, I think it's very reasonable for a ContentView (comment widget) to compose a Body Section and an Author Info section where both those latter two objects have a full reference to an EventEmitting Content Model. And they can call setters on that Content if they need to change the Content state and other Views would react. DOM Interactions bubble up to ideally as broadly scoped mediating controller as possible.

I have currently been planning on refacotring parts of the following codebase, and planning on splitting this Class into a few components that would work like what's described above. https://github.com/Livefyre/streamhub-sdk/blob/master/src/co...

Anyway, I think a combination is what works best. I'm curious what others think.

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 argue this is a design issue with the app itself. What good reason do various controllers have to communicate w/ one another?