Everything new is well forgotten old

Mary Evans Picture Library / Alamy - Ellis, R. 1994. Monsters of the Sea. Robert Hale Ltd.

A string of frameworks and libraries of the trends of the world JavaScript on the throne in turn is no longer a news. Developers from other areas even make fun of us about this.

So, in the process of work, I had to jump on various libraries and frameworks - qooxdoo, jQuery, Ext JS, Backbone.js, Knockout.js, Ember.js, Angular, React.
')
The choice of this or that framework was not always voluntary, the model outsource and outstaffing imposes certain restrictions on my work. I think people from this area will understand me.

The last thing I stopped at is React from Facebook. I will not hide, colleagues will confirm, I reluctantly switched to this library, the transition meant going out of the comfort zone, and this is something that we do not like so much. Scarecrow, many new words, in particular, the “new” rethinking of the architectural style in the person of Flux and Redux, “new” terms - Actions, Store, Dispatcher, etc.

Agree with all the previous "hammers and nails" the dictionary was usually reduced to something like Model-View- * (Controller || Presenter || Adapter || ViewModel || Whatever)

My understanding of this vocabulary looked exactly like this picture:


This is a picture from the “JavaScript Design Patterns” course of one of the rather popular MOOC-platform Udacity

I liked this picture. So it was easier to perceive the world inhabited by a bunch of clones and various MVC interpretations.

There is a View - this is html, css and all that with them. There is a Model - this is JSON-data and the place from which we pulled it. And there is a Kraken / Octopus / Centipede / Multi-pen - a kind of mythical creature combining data and ideas.

MVO is the answer to all questions.


And then suddenly Facebook comes along and says MVC is bad , you can get confused with it and then not get out of this network of dependencies:


And then he says that there is a silver bullet - Flux and Unidirectional Dataflow :


Then someone else comes along and says Flux is hard, Redux is what you need.
You tend to believe, because this is Facebook, these guys know a lot, gradually you succumb to the flow.

Now everything is solved by this architectural style and library. Need a front-end? Ok, we take React, Redux and a little more luggage in the form of thunk, saga, storybook, themr, flow and the trick.

No, you do not think, React is an excellent library. I am delighted with Virtual DOM technology, it really solves a very important task. Binding to the reactive programming paradigm is also something that makes me happy. But here is the “new” architectural style ...

Our industry is growing rapidly - this is good. In 2017, programmers are hundreds of times more than in 1980 - this is also good. There are a lot of cool tools designed to make life easier for an application programmer - this is also definitely good. But to think we, application programmers, are starting less. At least I think so. For 5 years of work of a professional programmer, I wrote a bunch of mediocre and confusing code.

For a minute, I decided to stop. And before going further, as well as Facebook, rethink the development of web applications. Understand why Unidirectional Dataflow is what solves the problem of this web, why nobody did this before Facebook and why MVC is so bad with its arrows in all directions.

And I began in the reverse order.

MVC

I began by going to see, and what is the definition of this architectural style given by other top-end development companies. After all, most often we do this, we are going to look to someone competent, to someone who has weight.

With the interpretation from Facebook, we met:


The following is an interpretation from Microsoft:


Model and View are not related in the opposite direction, although it is clear from the description that the model must respond to the state request from the view.

Those. in general, the interpretation is the same as that of Facebook.

We go to Apple, these guys have two shemeks (traditional and Cocoa API version)



HM interesting. The first option looks confusing. Here, as in previous interpretations, the model is associated with a representation in both directions. But the connection with the controller is no longer one-way. The user action passes through the view to the controller.

In the second version, the model and the presentation are no longer directly related. The interaction goes through the controller and it looks like a picture with an octopus.

And here is Google


Well, you understand, all the same kraken.


Below is a sketch from Martin Fowler's blog (by the way, he has a very interesting series of articles on GUI architectures , where he describes his MVC interpretation in detail):


Below is an MVC interpretation from a nearby world, such as Java. I am familiar with JSP firsthand. Dark past so to speak.


Are you not confused yet? Remember how in the series X-files? The truth is somewhere near.

One thing is clear, all the options are similar, they are all about the same thing, but there is no dogma in the interpretation of Model-View-Controller. Why is that? Apparently because the original wording was not so strict. Or maybe it was?

Often we judge a technology superficially. We take on faith other people's interpretations, instead of opening the source and forming their own opinion.

What is the source for MVC?

1970-80e

It was probably worth starting the article with the same question that Uncle Bob asks at his seminars.

Do you know who that is?


This is Trygve Reenskaug , a professor at the University of Oslo, the very creator of MVC, the man who first described this architectural style. It happened back in 1978, during his visit to the Learning Research Group at Xerox PARC, and the foundation was laid for this concept as the basis for the Dynabook project, an analogue of a modern tablet.

He is credited with the following quote:

MVC was conceived as the main solution to the user problem of controlling large and confusing data sets. The hardest part was the good names for the various architectural components. (approx. Wikipedia)

This is somehow contrary to the pictures from Facebook is this statement.

I was wondering how the creator himself portrays this architectural style. And here are a couple of interesting schemes of that era:




Interesting pictures, is not it? The first thing I really like about them is the appearance of the user. I think this is important for any scheme describing the architecture of client software.

The second interesting point is the unifying area for the controller and the view in the early circuits. Trygve defines it as Editor , and later Tool .

In his first note on this concept, four terms were defined: Model, Presentation, Controller, and Editor. An editor is an ephemeral component that a presentation creates on demand, like an interface between a view and input devices such as a mouse and keyboard.

After Tryguve left Xerox PARC, Jim Althoff and others implemented and implemented the first MVC version for the Smalltalk-80 class library; The professor was not involved in this work.

According to Professor Jim Altoff, the term “Controller” was interpreted in a slightly different way.

An important aspect of the original MVC was that its controller was responsible for creating and coordinating its subordinate views.

In later notes, the view accepts and processes user input related to itself. The controller accepts and handles input related to the Controller / View assembly as a whole, now called Tool .

By the way, Martin Fowler calls this tandem Presentation Layer .

In his work, Trygve makes a bias that the main players of any client system are the end user ( Mental Model ) and domain data ( Domain Model / Data ). And the main goal of MVC is to bridge the gap between the user's mental model and the digital model that exists in the computer.

This concept is still relevant today, despite the fact that it was the epoch of SmallTalk and the concept of web applications has not yet existed as such. User and data interaction is the essence of any program. Between these objects there is a layer through which they communicate with each other.


The basis of the interaction between the program and the person is always the input and output data streams. A generalized diagram would look like this:


Thus, I interpret the controller as a data entry point, and the view as an exit point. What is the entry point is a set of peripherals and view controls. At the same time, the view and the controller are implicitly connected but not directly communicating. The view delegates responsibility for sending a message about a user action to the controller.

The input stream is able to change the state of the subject model, but the model in turn should notify the user of its changes using the data exit point.


In one of the Trygve schemes, the controller and view one-to-many relationship. Why? I think because at that time any button or arrow on the user interface was a view. Has anything changed since that time? I think no.

In the interpretation of “kraken”, the submission is often understood as the whole page. In fact, it is always a tree of components. Each component may well play the role of a representation:



The relationship of the user interaction layer and the many-to-many model. This is also true for current programs, one page can display data and characteristics of various subject models, while the model in turn can be a data structure:


Let's try to formulate a generalized description of MVC:

• Model ( Model ) provides data and responds to controller commands, changing its state;
• The view is responsible for displaying model data to the user, responding to changes in the model;
• Controller ( Controller ) interprets user actions, notifying the model of the need for changes

It turns out some direct Unidirectional Dataflow :


Image from Wikipedia



Isn’t that what Facebook and Co offers?

• Store ( Store ) - data storage;
• Dispatcher - directs user action to the repository;
• View ( View ) - React-component tree;
• Action ( Action ) - user action, planar object;
• Action Creator - spawns an action (object);
• Reducer - changes the state of the data warehouse;

It turns out the revolution did not happen. Nothing changed. Everything is still through the prism of MVC. I see only another interpretation of this concept and the substitution of concepts.

What problems did the Facebook representatives talk about?

Perhaps we should start with the fact that over time the interpretation of the concept of segregation of duties of the system has been reduced to the implementation of specific templates.

Take a look at the Apple schemas. They describe the layers of the system with specific patterns: Listener, Strategy, Composition. This mistake has been drawn since the appearance of the “ Gang of Four ”.

The evolution of console software in the server and client also added its imprint on the original definitions.

Abstractions have become something concrete:


And as for the problems, the problems are the same and voiced for a long time. They will be the same for Flux / Redux. And for any other concept and framework. At first, you have a pure thought and you start with something simple. But over time, when you stop maintaining the purity of thought in your code, it turns into a scary kraken pasta monster. The project is starting to get bogged down in this tar pit.



Will Redux and Flux help me build the architecture of my project cleaner and clearer? Will they keep this pure thought? Are there any tools that will not allow to roll into the tangle of these arrows?

As tools and the next interpretation, they have the right to life. But on the current project, I began to slowly cut out Redux. Let's see what happens. Will it be possible for me to keep this pure thought or everything will once again turn into a swamp.

findings

Until cardinal changes occur in the field of Human-Computer Interaction, the whole concept will always be based on this:


Everything will go through this point of view. And the problem, of these hundreds of arrows in different directions, will live with this concept further.

It's just that someone manages to write cleanly, but someone still gets stuck in his own swamp.
And the edges of this concept are erased in the source code of this swamp. I know from experience, because I myself have turned a bunch of projects into this quagmire.

You probably want to ask the question: “ Well, cool uncle, and what's next? "
Nothing, treat this text as my Brain Dump.

Now I am glad that I still immersed myself in these terms and this “rethinking” of the development of the client layer of the web application. At least for myself, I began to interpret MVC in a new way. More abstract to interpret these terms.

I am also glad that I matured to publish my thoughts. Perhaps after some time my opinion will change and it will be interesting to return to this text and laugh.

PS Everything written above is my modest subjective opinion and my interpretation. And what is yours? I would be glad to see other points of view artur.basak.devingrodno@gmail.com

Article continuation
-> “The Mystery of the Kraken” - briefly about the history of MVC and others ,
-> “The Hunt for the Kraken” - Flux is difficult, Redux does not roll, we simplify everything to Artux

Links

→ MVC Wiki
→ Trygver MVC
→ Flux
→ Apple MVC (1)
→ Apple MVC (2)
→ Google MVC
→ Uncle Bob
→ Martin Fowler MVC