ReactJS for stupid people

Trying to figure out the Facebook library from 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 the translation of the first (and a little later, the second ) article with the Habrachians . 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 is an article that I once lacked.

What is React?


What is the difference between React and 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 a LEVEL of VIEW.

React is often mentioned alongside other javascript frameworks, but the React vs Angular debate doesn't make sense, because it's not comparable things. Angular is a complete framework (including presentation level). React - no. That's why React causes so much misunderstanding in the developing world of full-fledged frameworks - this is just an idea.

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

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

pros


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

1. You can always tell how your component will be rendered by looking at the source code.
This can be an important advantage, although it is no different from Angular templates. 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:



$.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 is changing the title? Who has access to the title? Who determines visibility? Manipulating the DOM is just as bad as the GOTO statement in your program logic.

Here's how you could do it with React:

render: function() {  
    return 
{ this.state.name ?
this.state.name
: null }
; }


We can tell right away how the component will be rendered. If you know the state, you know the result of the rendering. You do not need to track the progress of the program. When a complex application is being developed, especially as a team, this is very important.

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

Usually you separate views (HTML) and functionality (JavsScript). This leads to a monolithic JavaScript file containing all the functionality for one page, and you have to keep an eye on the complicated stream of JS-> HTML-> JS-> unpleasant situation.

Linking functionality directly to markup and packing it into a portable, stand-alone “component” will make you happier, and your code as a whole is better. Your Javasacript is “very familiar” with your HTML, so mixing them makes sense.

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

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

Minuses


Remember that React is just an idea .

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 alone is useless. Even worse, as we see, this leads to the fact that everyone invents his own bicycle.

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

image

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

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

image

35 KB gzipped
This is without a library in reacat-with-addonsthat 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!

The size of React is comparable to Angular, although Angular is a complete framework. React is, frankly, bold for such little functionality. Hopefully this will be corrected in the future.

Stop saying “FLUX”


Perhaps the most annoying part when developing on React is Flux. Confusing even more than React. The inflated concept of “Flux” greatly interferes with 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 is more a pattern than a 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 any new data management concept.

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

The unidirectional data stream and the observer design pattern ensures that your repositories / models are always up to date. This is useful.

The bad side of Flux is that everyone reinvents it. There is no agreement on the event library, model layer, AJAX layer and the rest, there are many different Flux implementations 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 adherence to the UI, and workflow template;
  • The UI code is readable and easy to maintain;
  • UI development 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. It’s not easy to understand how props, state work and how components interact, and the documentation is a “maze of information”. In theory, this can be solved quickly if an entire 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 wheel. React is young, so there are no established practices. Does your application need dropdown, resize windows or lightbox? You will have to write it all from scratch.


Bottom line:

Read the next post: "Flux For Stupid People" ( on the hub ).

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

Also popular now: