3r3-31. Hi, Habr!
 
 
We are with a sense of incredible pride and relief tonight we have handed over a new book on React
to the printing house.  
 
 
 
On this occasion, we offer you a slightly abridged translation of the article by Dan Abramov, which tells about the use of interceptors in the 16th version of React. In the book, which we ourselves are already looking forward to, it is described in the 5th chapter.
 
Sophie Olpert presented the concept of "interceptors" at the React Conf conference, followed by a detailed 3r-323. analysis of the topic
from Ryan Florence .
 
 
I strongly recommend watching this plenary lecture to familiarize yourself with the range of problems that we are trying to solve with the help of interceptors. However, I appreciate even the hour of your time very highly, so I decided to briefly set forth in this article the main considerations on interceptors.
 
3r3333. Note: React interceptors are still experimental. No need to delve into them right now. Also note that in this publication my personal views are set out, which may not coincide with the position of React developers. 3r3334. 3r33333. Why are interceptors needed? 3r33333.
 
 
It is known that component organization and downstream data flow help organize large UI in the form of small, independent and reusable fragments. 3r33333. However, it is often not possible to break up complex components beyond a certain limit, since logic preserves the state and is non-extractable into a function or some other component 3r33316. . Sometimes those who say that in React it is impossible to achieve “separation of duties” complain about this.
 
Such cases are very common, and are associated, for example, with animation, processing forms, connecting to external data sources and many other operations that we may need to perform with our components. Trying to solve such problems with the help of components alone, we usually get: 3r33333.  
 
 
3r361. 3r33333. Giant components [/b] which are difficult to refactor and test.
 
3r361. 3r33333. Duplication of logic [/b] between different components and life cycle methods.
 
3r361. 3r33333. Difficult patterns [/b] in particular, rendering properties (render props) and higher order components.
 
3r366.
 
We believe that interceptors are the most promising for solving all these problems. 3r33333. Interceptors help organize the logic inside the component in the form of reusable isolated units 3r3333316. :
 
 
3r375.
 
 
3r380.
 
 
3r33333. Interceptors correspond to the React philosophy (explicit data flow and composition) and within the component, and not just between components 3r3316. . That is why it seems to me that interceptors fit naturally into the model of React components.
 
 
Unlike patterns such as rendering properties or higher-order components, interceptors do not burden your component tree with overly deep embedding. Also they do not have those disadvantages which are inherent in impurities.
 
 
Even if at first glance interceptors are jarring you (just like me at first!) I recommend giving this option a chance and experimenting with it. I think you will like it.
 
 
3r33333. Is React swelling due to interceptors? 3r33333.
 
 
Until we look at the interceptors in detail, you may be worried that adding interceptors to React is just a multiplication of entities. This is a fair criticism. I think this: although in the short term you really feel an extra cognitive load (to study them), in the end it will only become easier for you.
 
 
3r33333. If interceptors take root in the React community, then in fact, 3r-3112. shrink 3r3113. the number of entities that have to be managed when writing React [/b] applications. . With the help of interceptors, you can constantly use functions, and not switch between functions, classes, higher order components and component rendering.
 
 
With regard to increasing the size of the implementation, the React application, with the support of interceptors, increases by only about ~ 1.5kB (min + gzip). While this is not too much in itself, it is very likely that 3r33333. when using interceptors, the size of your assembly will even decrease 3r33316. Because interceptor code is usually minified better than equivalent code using classes. The example below is slightly extreme, but it clearly demonstrates why everything is exactly like this ( Click To expand the whole thread):
 
 
 
 
3r33333. There are no revolutionary changes to the interceptor proposal. 3-333316. . The code you have will work fine, even if you start using interceptors in new components. In fact, this is exactly what we recommend: do not rewrite anything globally! It will be reasonable to wait until the use of interceptors is established in all critical code. Still, we will be grateful if you can experiment with the alpha version 16.7 and leave us feedback on 3r3133. interceptor proposal
, as well as 3r3136. Report any bugs
.
 
 
3r33333. What is it - interceptors? 3r33333.
 
 
In order to understand what interceptors are, you need to go back a step and think about what code reuse is.
 
 
Today, there are many ways to reuse logic in React applications. So, to calculate something, you can write simple functions and then call them. You can also write components (which themselves can be functions or classes). The components are more powerful, but when working with them you need to display some UI. Therefore, it is inconvenient to transfer non-visual logic with the help of components. So we come to complex patterns like property rendering and to higher order components. 3r33333. Wouldn't React be easier if there was only one common way of reusing code, and not so much? 3r33333.
 
 
It seems that the functions are ideal for reusable code. Transferring logic between functions is less expensive. However, the local React state cannot be stored inside functions. You cannot extract behavior like “monitor window size and update state” or “animate value for some time” from a class component without restructuring the code or introducing such abstractions as observable objects (Observables). Both approaches only complicate the code, and React is pretty nice to us.
 
 
Interceptors solve exactly this problem. Thanks to interceptors, you can use the capabilities of React (for example, state) from a function - by calling it only once. React provides several built-in interceptors that correspond to React “bricks”: state, life cycle, and context.
 
 
3r33333. Since interceptors are normal jаvascript functions, you can combine the built-in interceptors provided in React to create “your own interceptors” 3r33316. . Thus, complex problems can be solved with a single line of code, and then multiplied in your application, or 3r3168. share it in the React
community.
 
 
Warning: strictly speaking, your own interceptors are not among the React features. The ability to write your own interceptors naturally flows from their innermost organization.
 
 
3r33333. Show the same code! 3r33333.
 
 
Suppose we want to sign the component to the current width of the window (for example, to display other content or a narrower viewing area).
 
Such code today can be written in several ways. For example, make a class, create several life-cycle methods, or maybe even resort to rendering properties or use a higher-order component if you expect to be reusable. However, I think nothing compares to this:
 
 
3r3190.
 
 
gist.github.com/gaearon/cb5add26336003ed8c0004c4ba820eae
 
 
3r33333. If you are reading this code, it means that it does exactly what it says [/b] . We use the width of the window inside our component, and React redraws your component if it changes. It is precisely behind this that interceptors are needed - to make the components truly declarative, even if they contain a state and side effects.
 
 
Consider how you could implement this own interceptor. We could use the local state of React to keep the current width of the window in it, and use a side effect to set this state when the window is resized: 3r33333.  
 
 
 
gist.github.com/gaearon/cb5add26336003ed8c0004c4ba820eae
 
 
As shown above, React's built-in interceptors like 3r33333. useState and useEffect serve as "bricks". We can use them directly from our components, or we can assemble our own interceptors from them, for example, 3r33333. useWindowWidth . Using your own interceptors is no less idiomatic than working with the built-in React API.
 
 
Learn more about the built-in interceptors described in 3r3323291. This review is 3r33351. .
 
 
3r33333. Interceptors are encapsulated — whenever an interceptor is invoked, it gets an isolated local state inside the component that is currently running 3r-3316. . In this particular example, this is not important (the width of the window is the same for all components!), But this is precisely the strength of the interceptors! They are intended to separate not the state, but the logic that preserves the state. 3r33333. We do not want to break downstream data! 3r33333.
 
 
Each interceptor may contain some local state and side effects. You can transfer data between multiple interceptors, just as is usually done between functions. They can take arguments and return values ​​because they are jаvascript functions.
 
 
Here is an example 3r33351. React animation library, where we experiment with interceptors:
 
Notice how the stunning animation is implemented in the demonstrated source code: we pass the values ​​between several of our own interceptors within the same rendering function.
 
 
 
 
codesandbox.io/s/ppxnl191zx
 
 
(This example is discussed in more detail in 3r3r-3269. This manual, 3rr-3351.)
 
 
Thanks to the ability to transfer data between interceptors, they are very convenient for translating animations, data subscriptions, managing forms, and working with other stateful abstractions. 3r33333. Unlike rendering properties or components of a higher order, in the case of interceptors in your rendering tree, a “false hierarchy” of 3r-3316 is not created. . They look more like a two-dimensional list of “memory cells” attached to a component. No additional levels.
 
 
3r33333. What about classes? 3r33333.
 
 
In our opinion, own interceptors are the most interesting detail in the whole sentence. But in order for their own interceptors to work, React must provide at the function level the ability to declare state and side effects. This is what allows us to do built-in interceptors like 3r33333. useState and useEffect . Read more about this in documentation .
 
 
It turns out that such built-in interceptors are convenient not only when creating your own interceptors. They are also sufficient for identifying components as a whole, since they provide us with the necessary capabilities — for example, a state. That is why we would like in the future interceptors to become the primary means for identifying React components.
 
No, we do not plan to gradually abolish classes. We use tens of thousands of class components in Facebook and we (just like you) absolutely do not want to rewrite them. But, if the React community starts using interceptors, it will be inappropriate to keep the two recommended ways of writing components. Interceptors cover all those practical cases in which classes are used, but they give greater flexibility in extracting, testing, and reusing code. That is why we associate with interceptors our ideas about the future of React.
 
 
3r33333. What if interceptors are magic? 3r33333.
 
 
Perhaps interceptor rules you are puzzled.
 
 
3r33333. Although it is not customary to call the interceptor at the top level, you probably would not want to determine the state in the condition yourself, even if you could. . For example, a condition linked to a condition cannot be defined in the classroom, and for four years of communicating with React users, I have not heard any complaints about this.
 
 
Such a design is crucial for the introduction of your own interceptors without the simultaneous introduction of excessive syntactic noise or the appearance of pitfalls. We understand that being unaccustomed is difficult, but we believe that this compromise is acceptable, given the possibilities it offers. If you do not agree - I suggest experimenting and trying out how you like this approach.
 
 
We have been using interceptors in production for a month to check if programmers are confused by new rules. Practice shows that a person is mastered with interceptors in a matter of hours. I confess that at first glance these rules seemed to me to be heresy too, but this feeling quickly passed away. That was the impression I had when I first met React. (You didn’t like React? I only liked it a second time.) 3r3333372.  
 
Note: there is no magic at the interceptor implementation level either. Like writes Jamie , it turns out like this:
 
 
3r33333.
 
 
3r33333. gist.github.com/gaearon/62866046e396f4de9b4827eae861ff19
 
 
We maintain an item-based list of interceptors, and proceed to the next component in the list every time after using the interceptor. Due to the rules of interceptors, their order is the same in any rendering engine, so with each call we can provide the component with the correct state.
 
 
( In this article from Rudi Yardley Everything is beautifully explained in pictures!) 3r33333.  
 
You might have wondered - and where React stores the state of interceptors. In the same place where the state of classes. React has an internal update queue that contains the ultimate truth for each state, no matter how you define your components.
 
 
Interceptors are independent of proxies and getters, which are so common in modern jаvascript libraries. Therefore, it can be argued that there is less magic in interceptors than in other popular approaches to solving such problems. No more than array.push and array.pop (in the case with which the order of calls is also important!) 3r3333372.  
 
Interceptor design is not tied to React. In fact, already a few days after the publication of the proposal, various people showed us experimental implementations of the same interceptor API for Vue, web components, and even for ordinary jаvascript functions.
 
Finally, if you are fanatically devoted to functional programming, and you feel uncomfortable in your heart when React begins to rely on a changeable state as an implementation detail. But, perhaps, you will be comforted that the processing of interceptors can be fully realized in a pure form, limiting it only to algebraic effects (if they were supported in jаvascript). Naturally, at the intra-system level, React has always relied on a variable state — and that’s what you would like to avoid.
 
 
No matter what point of view is closer to you - pragmatic or dogmatic - I hope that at least one of these options seems logical to you. Most importantly, in my opinion, interceptors simplify our work, and it becomes more convenient for users to work. This is what interceptors bribe me so much. 3r33380.
3r33380.