Why you might not need MVC with React.js

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 in their application.

Contrast that with the front end/back end metaphor of the early internet, which was very easy for people to understand. It perfectly matched the way they had interacted with their bank, or command line tools, or even television. Hard to get much simpler than that!

I think where MVC went wrong is that it tried to bring a portion of the back end (the model) into the front end (the view) and call it a “controller” without effectively explaining what that meant. To me, backbone.js seemed like mainly a cache of the server. As in, there are a multitude of other ways to do what it does, from XMLHttpRequest, to a nested iframe, to just manually writing a bunch of javascript that encodes the controller. I found that it simplified the easy work of translating from a rest API to objects, but did almost nothing for the hard work of choreographing how all the parts worked together. I never got far with Angular.js but my impression of it is that it replaces one complex choreography for another.

My hunch is that the solution to all of this is a better data-object mapping that removes most of the code and works more like a graph, the way MS Access or Filemaker do, since most of the web is just CRUD apps anyway. The message passing of objective-c is an ok way to accomplish this, but it needs to be generalized and will probably work more like the Actor model:

https://en.wikipedia.org/wiki/Actor_model

So MVC will be replaced with automatons that run in their own sandboxes and interact with each other through explicitly specified channels, the way that Go works. A high level example of this is that you wouldn’t encode a select box to be enabled/disabled based on a boolean in some JSON, but that the select box would simply be inaccessible for certain data because its container actor would be in another state. If you think about this, it mirrors how unix works, with a set of very simple functions and permissions that dictate what can do what. I was first exposed to this style of programming in HyperCard back in the 80s, then later in Flash and Unity. One thing I would change about it today though is to remove the notion of time so that it works like MS Excel or functional programming, so that all of the states can be exercised and unit tests basically become an enumeration of all the states you want the program to arrive at.

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

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

That's funny, because in my opinion, the functionality of the model, data without display logic, is obvious, and the view is obvious, layout for data. but the line between the controller and the view seems very nebulous. At which point is the data general enough to warrant a new view, or specific enough to need only a controller to marshal between the view and the data... It seems to me that a Model->Controller->Widget is a much more strong distinction, where Widgets are simply things offered via the toolkit, or controller functionality that is made general once you find yourself wanting to use similar render for multiple pieces of data.

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 data

View: on-screen representation of Model; reacts to changes in Model to re-draw accordingly

Controller: maps user input to changes in Model; may need to interact with Views, and may pass control through a hierarchy of Controllers, to determine the Model being manipulated

in other words, user-input data flows as: C -> M, and M -> V. i see a Controller modifying a View (rather than just querying it) as impure MVC, and i normally strive to avoid it, even though that's essentially impossible if you're forced to use a platform's GUI toolkit.

i don't think of MVC as having "gone wrong," but rather that the name has been co-opted and the pattern corrupted by so many different people, in many different ways, as to make the original name extremely confusing. iOS' concept of "MVC" drives me crazy. i think it's probably fair to call it MVP (Model-View-Presenter), the difference being that the Presenter can indeed do some of the work of modifying the View. but i still mostly think of this as a hack: the more work that gets shoved into the Presenter, the more complicated it gets.

I wish I could see where you're coming from, but it doesn't seem simpler to me as compared to angular, just different. I need to read through the code for React like I did for Angular.