Speak the word about Brave React
Hello, dear readers!
We are glad to make you happy - we are already doing the translation of the book by the well-known Stoyan Stefanov about the React library
We thought that this young sprout on the massive stem of JavaScript would be useful to advertise carefully, so we suggest reading the review and slightly enthusiastic article, which, in our opinion, is outdated by just a couple of paragraphs (we omitted them)
React has already become one of the most promising protagonists among the JavaScript frameworks. This tool is simple and easy to use, but, nevertheless, it is extremely difficult to clearly articulate its merits, proving the viability of React as such. Even the authors of the project themselves admitted that, starting to develop it, they could not quite answer such questions.
')
Two major objections to React's peak are:
I will try to highlight both of these problems, as well as focus on some of the strengths of React. So let's go!
So what is React?
React is a javascript library for creating components. Each component has an “appearance”, which is defined by the render method and some states defined in
Example:
In this example we have a button, when clicked, the increment method is called. The
The
Of course, in React you will have to get acquainted with many other concepts - for example, properties (props), various attributes of tags - but the DOM is the most important.
What reacts blamed
Incompleteness. Good or bad?
When Rails appeared, their "full-body" was especially advertised in them (I hope there is such a word). Since then, none of the alternatives have turned out to be so self-sufficient — after all, Rails has a level of database abstraction, a routing system, a templating engine, and so on.
As far as I know, the first of the alternatives was Camping from Why - a microframe, consisting of a few lines of code. He was followed by Sinatra, CherryPy, Flask, Express and many others. But the fact is that they all continue to emulate the concept of the framework, they just get a little thinner, and are also written less biased. And these tools are sold due to the fact that there is not much fuss with them and, accordingly, they are more convenient for developing relatively small applications.
That incompleteness, which is different React, is fundamentally different. React is not just a lightweight Angular, but something fundamentally different. It does a very good job with a specific task: it works with web components. So, it’s wrong to talk about how big our project should be. By the way, React was focused on performance, it is on it that the Facebook comment system works - therefore, it is beyond doubt able to work on a colossal scale.
Here is something to think about: do you need a full-fledged framework and, in addition, can you organize all the necessary components on the basis of React. First of all, it should be noted that the size of the machine interface is essentially not important. If you have to load a 1GB framework, but the output is a flexible and fast application, this is not a problem. On the other hand, the size of the front end is very important. Any additional load from your framework will immediately affect the final result.
There are other great features in React, thanks to which it is perceived as a full-fledged framework. I know many examples of mixing Backbone models into React. There are excellent libraries for adding routing . But one of the main achievements of the React community is, of course, Flux , although this is not so much a set of tools as an approach to the architecture of the application.
Is it true that React is just V of MVC abbreviation?
As Andre Medeiros notes in his excellent presentation, the possibilities of React are far from being limited to V. The fact is that the React components have a state, therefore such a component is, in a sense, a Model. It provides a display of input on the state change, therefore, at the same time, has the features of a controller, or even views, emphasizes Medeiros. The component also communicates with other components and depends on them. So, you do not have to look for suitable libraries for the model and controller - a similar opinion is simply a mistake.
And since React contains all these things in the form of a solid concept — a component — it opens up tremendous opportunities to write randomly strongly related code in which the division of responsibility is poorly implemented.
Medeiros proposes to solve these problems by adopting the MVI principle - Model-View-Intention — that is, it promotes a rather peculiar approach to web development. One of the implementations of this approach is called a loop .
Why mix HTML and JS? …What? And CSS too ???
Ten years ago, web development had its own sacred cow - a separation of HTML, JS and CSS. All three technologies were supposed to exist by themselves, in separate files and directories. These files could only refer to each other, which was done with the help of inclusions.
No matter how harmoniously this separation looks, this is just a distinction between technologies, but not responsibility. React casts doubt on this approach, clearly regulating that the separation should occur at the component level. Components can mix different technologies, but each component is a well-encapsulated and fitted element, it looks logical and functions logically. If various technologies and languages ​​are involved in this functionality, then so be it.
All this can cause rejection, which, in my opinion, is explained by pure unreasonable prejudices. Just a few hours you get used to. All opinions on React that I found on the Internet are essentially the same. Suddenly you get rid of the need to keep two open files in the adjacent tabs - and the productivity of work increases dramatically.
Some even advocate moving the entire CSS to the component area. Before branding me, see an interesting presentation on this topic from Christopher Chadau.
React Defense Arguments
There is an ecosystem here.
I am writing this article, and React has just bypassed Ember by rating on GitHub. It is inferior to Backbone and, of course, Angular, but grows much faster than the "competitors".
React is a Facebook project, it is on it that the commenting system on Facebook and most of the projects of this company are implemented. In addition, React is widely used in Pinterest, AirBnB, Khan Academy and a host of other startups. On the basis of React built editor Atom, moreover, and Microsoft supports React.
Thus, I try to prove that React is already mainstream, as far as we can speak about the mainstream in the technological landscape of JavaScript tools. This means that you do not have to worry too much about the support of the project, whether it will become an ecosystem. It is already possible to make sure that there is a cloud of libraries for React - although, for the time being, it is difficult for me to judge their quality.
Easier to judge the code
One of the main arguments in favor of React is related to its logic. This is an extremely true statement, and its weight and importance should not be underestimated.
Judging about the code, in my opinion - it is not easy to be able to isolate weakly and strongly connected sections in it. This means, to logically follow from the awareness of the problem to an understanding of where and what is happening (events, data streams ...), quickly assess these elements and, finally, fix the problem.
An interesting thing: thinking about the quality of the program, you need to pay attention not only to the number of bugs - we in Agile generally preach the idea that “there should be no bugs” - but also how long it takes to fix the bug. Having assimilated this idea, I remembered a bug that I managed to get rid of only a year later. He made monstrous memory leaks and significantly slowed down the entire program, especially at peak loads. If we proceed only from the number of bugs, then, quite possibly, you will have only a handful of such flaws, but the solution itself will still be very bad.
So, the duration of the removal of a bug indicates whether it is difficult to judge the code. If the removal of a bug takes a lot of time, it means that developers have to pretty much build on the problem before it is discovered - and vice versa.
React simplifies reasoning about code, and for several reasons at once. Basic –DOM stateless. For example, consider how switching is implemented in traditional jQuery:
At first glance, everything is simple. But here's the catch: how do you know if the div is displayed? Yes, you can say: “If you press the button button any even number of times, it will be displayed, and if not, it will not be displayed.”
And now the situation is changing radically. You can say: "It is displayed if visible." The iron rule is: if your code is easy to understand, then express something in this code can be much clearer.
Reuse
This is a magic word. In the world of backend, reusing code fragments is a reality. It can be, for example, about gems or eggs. But in the client side it may seem that for every new project everything has to be re-assembled. Indeed, things like the DOM crawl tool or URL parser are easy to reuse, but when it comes to content as such, each project begins to look different, and each element of the layout is original, which does not fit with the same brush.
I admit, I have not yet met the components to migrate from one project to another, but I see no reason why atomic entities like notification windows and buttons, and even more “molecular” or “organic” things, such as articles or lists tasks could not be used "as is" if you separate the visual design from the markup and behavior.
It would be interesting to see repeated use of the same developments in different companies, to see how people will write free libraries with implemented components. A good example is MaterialUI .
Growing project
Many client projects I have worked on were initially very small and then grew significantly. Some underwent refactoring and acquired a completely different structure, or at some point an improvised structure was introduced in them, which was supposed to help cope with the increasing complexity. In both cases, such work requires a lot of time and effort - however, like any important refactoring, which allows to significantly speed up development later.
One important feature of component-based development is that it blends very organically with these stages of the project’s evolution. I can not imagine that a project that began with a small set of components and a neatly organized data flow requires such radical changes - after all, all its parts are very stable.
That's all. Actually, here I almost did not touch on the topic of Flux, but this is already material for a completely different article.
We are glad to make you happy - we are already doing the translation of the book by the well-known Stoyan Stefanov about the React library
We thought that this young sprout on the massive stem of JavaScript would be useful to advertise carefully, so we suggest reading the review and slightly enthusiastic article, which, in our opinion, is outdated by just a couple of paragraphs (we omitted them)
React has already become one of the most promising protagonists among the JavaScript frameworks. This tool is simple and easy to use, but, nevertheless, it is extremely difficult to clearly articulate its merits, proving the viability of React as such. Even the authors of the project themselves admitted that, starting to develop it, they could not quite answer such questions.
')
Two major objections to React's peak are:
- Its incompleteness - React is not a “full-window” framework, unlike Meteor or Angular. It does not have a router, a system of models, and many other features that the framework is supposed to have. They say that it implements only “V” from MVC, but this is far from the case, which is what I am going to talk about.
- Its syntax is HTML and Javascript are mixed here. The programmer looks at JSX and asks: “but ... why?”. And some even advocate mixing in CSS.
I will try to highlight both of these problems, as well as focus on some of the strengths of React. So let's go!
So what is React?
React is a javascript library for creating components. Each component has an “appearance”, which is defined by the render method and some states defined in
getInitialState . Appearance depends on the current state. That, in essence, is all. And this is why it is so difficult to explain React - for many it causes just such a feeling of “incompleteness”.Example:
Counter = React.createClass getInitialState: -> count: 0 increment: -> @setState(count: @state.count + 1) render: -> <div> { @state.count } <button onClick={ @increment }>+</button> </div> In this example we have a button, when clicked, the increment method is called. The
increment method calls setState, so a new number is set, one more than the current one.The
setState method again displays the component. This is done in such an original way that it is in this that React and its clones differ from similar tools. In essence, React stores a document object model in memory called the “virtual DOM” (“shadow DOM” is a slightly different phenomenon) and then calculates the difference between this DOM and the one displayed in the browser. Based on this difference, a list is made of the changes that need to be made — imagine createElement — and then these changes are applied.Of course, in React you will have to get acquainted with many other concepts - for example, properties (props), various attributes of tags - but the DOM is the most important.
What reacts blamed
Incompleteness. Good or bad?
When Rails appeared, their "full-body" was especially advertised in them (I hope there is such a word). Since then, none of the alternatives have turned out to be so self-sufficient — after all, Rails has a level of database abstraction, a routing system, a templating engine, and so on.
As far as I know, the first of the alternatives was Camping from Why - a microframe, consisting of a few lines of code. He was followed by Sinatra, CherryPy, Flask, Express and many others. But the fact is that they all continue to emulate the concept of the framework, they just get a little thinner, and are also written less biased. And these tools are sold due to the fact that there is not much fuss with them and, accordingly, they are more convenient for developing relatively small applications.
That incompleteness, which is different React, is fundamentally different. React is not just a lightweight Angular, but something fundamentally different. It does a very good job with a specific task: it works with web components. So, it’s wrong to talk about how big our project should be. By the way, React was focused on performance, it is on it that the Facebook comment system works - therefore, it is beyond doubt able to work on a colossal scale.
Here is something to think about: do you need a full-fledged framework and, in addition, can you organize all the necessary components on the basis of React. First of all, it should be noted that the size of the machine interface is essentially not important. If you have to load a 1GB framework, but the output is a flexible and fast application, this is not a problem. On the other hand, the size of the front end is very important. Any additional load from your framework will immediately affect the final result.
There are other great features in React, thanks to which it is perceived as a full-fledged framework. I know many examples of mixing Backbone models into React. There are excellent libraries for adding routing . But one of the main achievements of the React community is, of course, Flux , although this is not so much a set of tools as an approach to the architecture of the application.
Is it true that React is just V of MVC abbreviation?
As Andre Medeiros notes in his excellent presentation, the possibilities of React are far from being limited to V. The fact is that the React components have a state, therefore such a component is, in a sense, a Model. It provides a display of input on the state change, therefore, at the same time, has the features of a controller, or even views, emphasizes Medeiros. The component also communicates with other components and depends on them. So, you do not have to look for suitable libraries for the model and controller - a similar opinion is simply a mistake.
And since React contains all these things in the form of a solid concept — a component — it opens up tremendous opportunities to write randomly strongly related code in which the division of responsibility is poorly implemented.
Medeiros proposes to solve these problems by adopting the MVI principle - Model-View-Intention — that is, it promotes a rather peculiar approach to web development. One of the implementations of this approach is called a loop .
Why mix HTML and JS? …What? And CSS too ???
Ten years ago, web development had its own sacred cow - a separation of HTML, JS and CSS. All three technologies were supposed to exist by themselves, in separate files and directories. These files could only refer to each other, which was done with the help of inclusions.
No matter how harmoniously this separation looks, this is just a distinction between technologies, but not responsibility. React casts doubt on this approach, clearly regulating that the separation should occur at the component level. Components can mix different technologies, but each component is a well-encapsulated and fitted element, it looks logical and functions logically. If various technologies and languages ​​are involved in this functionality, then so be it.
All this can cause rejection, which, in my opinion, is explained by pure unreasonable prejudices. Just a few hours you get used to. All opinions on React that I found on the Internet are essentially the same. Suddenly you get rid of the need to keep two open files in the adjacent tabs - and the productivity of work increases dramatically.
Some even advocate moving the entire CSS to the component area. Before branding me, see an interesting presentation on this topic from Christopher Chadau.
React Defense Arguments
There is an ecosystem here.
I am writing this article, and React has just bypassed Ember by rating on GitHub. It is inferior to Backbone and, of course, Angular, but grows much faster than the "competitors".
React is a Facebook project, it is on it that the commenting system on Facebook and most of the projects of this company are implemented. In addition, React is widely used in Pinterest, AirBnB, Khan Academy and a host of other startups. On the basis of React built editor Atom, moreover, and Microsoft supports React.
Thus, I try to prove that React is already mainstream, as far as we can speak about the mainstream in the technological landscape of JavaScript tools. This means that you do not have to worry too much about the support of the project, whether it will become an ecosystem. It is already possible to make sure that there is a cloud of libraries for React - although, for the time being, it is difficult for me to judge their quality.
Easier to judge the code
One of the main arguments in favor of React is related to its logic. This is an extremely true statement, and its weight and importance should not be underestimated.
Judging about the code, in my opinion - it is not easy to be able to isolate weakly and strongly connected sections in it. This means, to logically follow from the awareness of the problem to an understanding of where and what is happening (events, data streams ...), quickly assess these elements and, finally, fix the problem.
An interesting thing: thinking about the quality of the program, you need to pay attention not only to the number of bugs - we in Agile generally preach the idea that “there should be no bugs” - but also how long it takes to fix the bug. Having assimilated this idea, I remembered a bug that I managed to get rid of only a year later. He made monstrous memory leaks and significantly slowed down the entire program, especially at peak loads. If we proceed only from the number of bugs, then, quite possibly, you will have only a handful of such flaws, but the solution itself will still be very bad.
So, the duration of the removal of a bug indicates whether it is difficult to judge the code. If the removal of a bug takes a lot of time, it means that developers have to pretty much build on the problem before it is discovered - and vice versa.
React simplifies reasoning about code, and for several reasons at once. Basic –DOM stateless. For example, consider how switching is implemented in traditional jQuery:
// html <section> <div class="toggled">HERE I AM</div> <button class="toggler">Toggle!</button> </section> // coffescript $('.toggler').on 'click', -> $('.toggled').toggle() At first glance, everything is simple. But here's the catch: how do you know if the div is displayed? Yes, you can say: “If you press the button button any even number of times, it will be displayed, and if not, it will not be displayed.”
Toggler = React.createClass getInitialState: -> visible: true toggle: -> @setState(visible: !@state.visible) render: -> <section> { @state.visible && <div>HERE I AM</div> } <button onClick={ @toggle }>Toggle!</button> </section> And now the situation is changing radically. You can say: "It is displayed if visible." The iron rule is: if your code is easy to understand, then express something in this code can be much clearer.
Reuse
This is a magic word. In the world of backend, reusing code fragments is a reality. It can be, for example, about gems or eggs. But in the client side it may seem that for every new project everything has to be re-assembled. Indeed, things like the DOM crawl tool or URL parser are easy to reuse, but when it comes to content as such, each project begins to look different, and each element of the layout is original, which does not fit with the same brush.
I admit, I have not yet met the components to migrate from one project to another, but I see no reason why atomic entities like notification windows and buttons, and even more “molecular” or “organic” things, such as articles or lists tasks could not be used "as is" if you separate the visual design from the markup and behavior.
It would be interesting to see repeated use of the same developments in different companies, to see how people will write free libraries with implemented components. A good example is MaterialUI .
Growing project
Many client projects I have worked on were initially very small and then grew significantly. Some underwent refactoring and acquired a completely different structure, or at some point an improvised structure was introduced in them, which was supposed to help cope with the increasing complexity. In both cases, such work requires a lot of time and effort - however, like any important refactoring, which allows to significantly speed up development later.
One important feature of component-based development is that it blends very organically with these stages of the project’s evolution. I can not imagine that a project that began with a small set of components and a neatly organized data flow requires such radical changes - after all, all its parts are very stable.
That's all. Actually, here I almost did not touch on the topic of Flux, but this is already material for a completely different article.
Source: https://habr.com/ru/post/316684/
All Articles