Eureka! Moments of insight when studying React

Svetlana Shapovalova, the editor of Netologiya , translated an article by Tyler McGinnis, in which he listed the main points of insight that arise when studying React.



One of my main teaching tasks is to make people more often have moments of insight. “Eureka!” Is a moment of sudden clarification, when previously incomprehensible facts suddenly make sense. It happened to everyone. I am familiar with many teachers and the best of them are able to teach a lesson in such a way that students can get inspiration much more often.

In the past few years, I have taught React with all possible methods. All this time I have been making detailed notes on what provokes such “Eureka!” Moments.
')
I recently stumbled upon a Reddit thread where the same idea was discussed. The discussion inspired me to write this article, in which I shared the main learning insights. I hope it helps you to take a fresh look at how to work with React.

Illumination number 1. Props for components - the same as arguments for functions.

What is good in React: the very instinct you use for JavaScript functions can be used to understand where and when you need to create React components. The difference between React is this: instead of taking some arguments and returning a value, your function will take some arguments and return an object representation of your user interface (UI) .

This idea can be expressed by the formula fn (d) = V. It reads like this: “the function takes some data and returns a representation”.

This is a great way to imagine the development of user interfaces - now your UI simply consists of various function calls. This is like building apps. Now you can take full advantage of the composition of functions when creating user interfaces.

Illumination number 2. In React, the user interface of your application is completely built using composition functions. JSX is an abstraction of these functions.

The most common reaction that I see for those who use React for the first time looks something like this: “React is cool, but I don’t like JSX. It destroys the division of responsibility. ” JSX is not trying to be HTML . And it is definitely more than just a template language. There are two important things to understand about JSX.

First, JSX is an abstraction over React.createElement, a function that returns an object representation of a DOM.

Every time you broadcast a JSX, you will have a JavaScript object representing the actual DOM — or any other representation of the platform you are on (iOS, Android, etc.). Then React will analyze this object and analyze the actual DOM. With diff, React can only update the DOM where the change occurred. This improves performance, but more importantly, it shows that JSX is actually "just JavaScript."

Secondly, precisely because JSX is just JavaScript , you get all the advantages of JavaScript: for example, composition, lintting and debugging. But you also still get declarative and similar to HTML.

Illumination number 3. Components do not have to match DOM nodes.

When you first get into React, you learn that “components are the building blocks of React. They take the input and return some interface (descriptor template). "

Does this mean that each component must directly return user interface descriptors, as we usually study? What if we want a component to display another component (a higher order component template)? What if we want the component to control some state section, and then instead of returning the user interface handle return the function call in the state (Render Props template)? And if we had a component that is responsible for managing the sound, and not for the visual interface, then what would it return?

In React, it's good that you do not need to return the typical "views" of your components. As long as the result returns an element React, null or false, everything is fine.

You can return various components:

render () { return } You can return function invocations: render () { return this.props.children(this.someImportantState) } Or you can return nothing at all: render () { return null } 

Illumination number 4. When the two components need to separate the state, you need to raise it, and not synchronize

Component architecture, of course, complicates the separation of states. If two components rely on the same state, then where should it be? It was such a popular question that it provoked the emergence of a whole ecosystem of solutions, and eventually Redux appeared.

Redux's solution is to put this shared state to another location called the repository. Components can subscribe to any parts of the repository they need, and can also send “actions” to update the repository.

The React solution must find the closest parent element for both of these components and force this parent to control the overall state, passing it to the child components as needed. Both approaches have their pros and cons, but it is important to know that both solutions exist.

Illumination number 5. Inheritance is not needed in React, and containment and specialization can be obtained using composition

Fortunately, React has always been very freethinking about the principles of functional programming. One example of transitioning React from inheritance to composition is release 0.13, when it became clear that React did not add support for Mixins with ES6 classes.

The reason for this is that almost everything that you can do with Mixins or inheritance can also be done through composition, but with fewer side effects. If you come to React with the inheritance mentality, then a new way of thinking may be difficult and unusual.

Illumination number 6. Separation of container and presentation components

If you pay attention to the structure of the React component, then it usually includes some state, some “hooks” of the life cycle and markup through JSX.

What if instead of putting all of this in one component, you could separate the state and life cycle hooks from the markup? You will have two components. The first will contain the state, life cycle methods, and be responsible for how the component works. The second will receive data through props and be responsible for how the component looks.

This approach allows you to reuse your presentation components more efficiently, since they are no longer associated with the data they receive.

I also found that it allows you and those who will delve into your project to better understand the structure of the application. You can replace the component implementation without seeing or not worrying about the user interface, and vice versa. As a result, developers can customize the user interface without worrying about how the presentation components receive data.

Illumination number 7. If you are trying to keep most components clean (pure), it will be much easier to maintain stateless elements.

This is another advantage of separating your presentation components from the components of your container. Condition - inconsistency mate. Having identified the right lines of separation, you will significantly improve the predictability of your application by encapsulating complexity.

Thank you for taking the time to read my article!

From the Editor

In-depth study of JavaScript is a long way. And the React library is just one of many points in the summary of a full-fledged front-end developer, and far from the very first.
If you want to have a good understanding of JavaScript, add a deep understanding of the Web API, learn how to solve problems in pure JavaScript, understand BOM and DOM, learn asynchronous HTTP requests (AJAX) and web sockets (WebSocket) - sign up for our advanced course “Front- end development: creating interactive web pages . ”