Trying to deal with the library from Facebook ReactJS and the Flux architecture promoted by the same company, I came across two interesting articles on the Internet: “ReactJS For Stupid People” and “Flux For Stupid People” . I decided to share with the habravchanami translation of the first (and a little later, the second ) article. So let's go.

ReactJS for stupid people

TL; DR For a long time I tried to understand what React is and how it fits into the structure of the application. This article, which I once lacked.

What is React?

What makes React different from Angular, Ember, Backbone and others? How to manage data? How to interact with the server? What the hell is JSX? What is a "component"?
')
STOP.

Stop right now.

React is ONLY LEVEL OF REPRESENTATION.

React is often mentioned alongside other javascript frameworks, but the “React vs Angular” disputes do not make sense, because these are not comparable things. Angular is a complete framework (including the presentation layer). React - no. That is why React causes so much confusion in the developing world of full-fledged frameworks - this is only a representation.

React gives you a template language and some callback functions for rendering HTML. The entire output of React is HTML. Your HTML / JavaScript bundles, called components, are committed to keeping their internal state in memory (for example: which bookmark is selected), but in the end you just spit out HTML.

Of course, you cannot build a fully functioning dynamic application only with React. Why, we will look at it later.

pros

After working with React, I saw three very important benefits.

1. You can always tell how your component will be drawn by looking at the source code.
This can be an important advantage, although it is no different from Angular patterns. Let's use an example from real life.

Let's say you need to change the title of your site to the username after login. If you are not using any MVC framework, you can do something like:

<header> <div class="name"></div> </header> 

 $.post('/login', credentials, function( user ) { // Modify the DOM here $('header .name').show().text( user.name ); }); 

From experience, I can say that this code will ruin the life of you and your colleagues. How to debug? Who changes the headline? Who has access to the header? Who determines visibility? DOM manipulation is as bad as the GOTO statement in the logic of your program.

Here's how you could do it with React:

 render: function() { return <header> { this.state.name ? <div>this.state.name</div> : null } </header>; } 

We can immediately tell how the component will be drawn. If you know the state, you know the result of the drawing. You do not need to track the progress of the program. When developing a complex application, especially in a team, it is very important.

2. Binding JavaScript and HTML in JSX makes components easy to understand.
A strange combination of HTML / JavaScript can confuse you. We were taught not to embed JavaScript in the DOM (for example: OnClick handlers), while we were “tiny” developers ( or: since we were wee developers ). But you can believe me, working with JSX components is really great.

Usually you separate the presentation (HTML) and functionality (JavsScript). This results in a monolithic javascript file containing all the functionality for a single page, and you should watch out for the complex stream of JS-> HTML-> JS-> unpleasant situation.

Linking the functionality directly to the markup and packaging it into a portable, self-contained "component" will make you happier, and your code as a whole is better. Your javasacript is “familiar” with your HTML, so it makes sense to mix them.

3. You can render React on the server.
If you are developing a public site or application, and you render everything on a client, then you have chosen the wrong path. Client rendering is the reason why SoundCloud is slow, and why Stack Overflow (using only server rendering) works so fast. You can render React on the server, and you should do this.

Angular and others encourage PhantomJS to render the page and provide it to search engines (based on the user agent) or to use paid services. DAMN!

Minuses

Keep in mind that React is just a show .

1. You will not receive the following:

1. Event system (different from native DOM events);
2. Work with AJAX;
3. Any data layer;
4. Promises;
5. A framework for all occasions;
6. Any thoughts on how to implement all of the above.

In the real world, React is useless by itself. Worse, as we can see, this leads everyone to invent their own bicycle.

2. Bad and incomprehensible documentation.
Again, this article is for stupid people. Look at the first part of the sidebar documentation:



Here are three separate, competing tutorials for beginners. This is surprising. The sidebar is below, as if from my nightmares, with sections that don't exactly have to be here, such as “More About Refs” and “PureRenderMixin” ( note of the translator: React plugin ).

3. React is large enough, considering how little you get from it, including poor cross-browser support .



35 KB gzipped
This is without a library in reacat-with-addons , which you will need to develop a real application!
This is without the ES5-shim library needed to support IE8!
This is without any other library!

In size, React is comparable to Angular, although Angular is a complete framework. React, frankly, bold, for such a small functionality. Let's hope that in the future it will be corrected.

Stop talking “FLUX”

Perhaps the most annoying part when developing on React is Flux. Confusing even more than React. The bloated concept of "Flux" greatly hinders understanding. There is no such thing as Flux. Flux is a concept, but not a library. Ok, there is a flux library with something like:

Flux pattern rather than framework

Ugh. Worst of all, React does not rethink the last 40 years of knowledge in the field of UI-architecture and does not come up with some kind of new data management concept.

The concept of Flux is simple: your view triggers an event (for example: the user enters a name in the text field), the event changes the model, then the model triggers the event, the view responds to the model event and is redrawn with new data. That's all.

Unidirectional data flow and the “observer” design pattern ensures that your vaults / models are always up to date. This is useful.

The bad side of Flux is that everyone reinvents it. So there is no agreement on the library of events, the model layer, the AJAX layer and the rest, there are many different implementations of Flux and they all compete with each other.

Should I use React?

The short answer is yes.

Detailed answer: unfortunately, yes, for many things.

Why you should use React:

• Great for team development, strict UI compliance, and workflow template;
• UI code is readable and easy to maintain;
• Developing a UI based on individual components is the future of web development, and you should start doing it now.

Why you should think twice before choosing:

• At the initial stage, React slows down the work. Understanding how props work, state, and how components interact is not easy, and documentation is a "maze of information." In theory, this can be resolved quickly if a whole team works on it;
• React does not support browsers from IE8 and younger, and never will;
• If your application / website is not saturated with a large number of dynamic pages, you will have to write a lot of code, solving small problems;
• You will reinvent the bikes. React is young, so there are no developed practices. Does your application need a dropdown, resize window or lightbox? You have to write all this from scratch.

Total:

Read the following post: "Flux For Stupid People" ( on Habré ).

I hope this article will help foolish people like me to better understand React. If this post has made your life easier, you can follow me on Twitter .