What is RxJS and why is it useful to know about it
In this article, we will share with you the translation of an interview with the project manager of RxJS 5+, Google engineer Ben Lesch .
In the vast world of front-end development, there are many interesting tools. I strive to find the right approach to the study of practical things, so I decided to talk with one of the most prominent representatives of the RxJS community, Ben Leshem. I wanted to learn more about RxJS, and why I, a novice developer, should invest time in learning reactive programming. In addition, I wanted to understand - why use RxJS in my projects. Ben told me about how to use RxJS and shared tips on learning this technology.
Programming is always a solution to problems and a search for tools suitable for finding answers to specific questions. In the case of RxJS, the problem to be solved is the ability to handle asynchronous calls using a variety of events. It is worth to dwell on this.
')
Imagine that you are writing a function that performs a certain sequence of actions with the data and that an error occurs during this work. If you simply use functions to process sequences of requests, there may be some optional actions taken to return an error. Instead of passing the error through all the functions, you need to be able to take the error and update the view without having to go through all the Ajax requests that are no longer needed.
You may notice that promises are created for organizing error handling in this style, but RxJS takes the concept of working with sequential actions to a new level. Promis can handle only a single value, which limits the use of this design. In addition, the promise cannot be canceled, which means that it can easily block the flow and waste resources (an important consideration for low-power devices).
In contrast, RxJS provides a way to eliminate these constraints by giving several communication channels, which simplifies the processing of multi-step events and increases its efficiency. RxJS, in addition, gives the developer the opportunity to consistently represent everything that needs to generate events. When everything looks the same, it turns out that it is very easy to work with all of this: to combine, combine, execute queries. All this makes RxJS a very powerful tool.
On the one hand, RxJS is a powerful tool that allows you to turn complex sequences of actions into concise code that is easy to work with.
On the other hand, this simplicity is based on a variety of linguistic mechanisms, and their study takes time. However, the knowledge gained is worth the effort, when you realize that with a single line of code you can do something like an implementation of the drag-and-drop mechanism, which requires three sets of events.
This makes it possible to tie these events together (pressing the mouse button, moving the mouse, releasing the button) in order to get one short and precise line of code. With the usual approach, this requires a program of several dozen lines.
One of the most attractive opportunities when integrating RxJS into code is that the more you use it, the more you can do with this technology. RxJS can be compared to Lego, in the sense that Lego is great for developing new designs, since all cubes have the same shape. Similarly, all the observed objects look the same, so creating something with their use becomes a fascinating task, since you can experiment with a lot of interesting solutions. The more someone uses observable objects in the code, the more opportunities they get in creating something new based on existing structures.
Observed objects can be used in almost any application. If we are talking about team development, it may take some time, however, the transition can be simplified if the following conditions are met:
Everyone masters these things at their own pace, but in the end, don't be surprised if you find that your team does everything with Rx. When observed objects are used to perform certain actions, they all look the same and they are much more interesting to use when more and more similar objects appear in the application.
Of course there are! If we have a separate event that performs a single action, as often happens in JS programming, then using RxJS is a little weird. Of course, here you can apply RxJS, but it will be an obvious search.
The implementation of the drag-and-drop operation is an excellent example of a problem for which RxJS is ideally suited. This is an event with a multitude of actions, the complexity of which, with such an opportunity, is always useful to reduce.
It is useful, when deciding whether to use observable objects, to rely on context. For example:
The list of operators to start with should include
You can narrow the list of used operators to less than ten of those that are required most often. There are, of course, operators to experiment with, like
The use of RxJS in React is very similar to its use in Angular, where it is fully implemented. In Angular, the observed objects are the full entities of the system, hence the particular simplicity of using this technology in Angular. However, it is no more difficult than subscribing to RxJS in
As with any other technology, in the course of studying Rx, debugging is simplified as the experience accumulates. There are some situations that are difficult to debug. I am currently working with the Chrome development team to solve these problems.
A typical difficult situation that programmers encounter occurs when they return something from a
Here are some debugging tips:
RxJS is expected to see several changes that are worth paying attention to. So, the so-called “lettable” operators will be available soon. Thanks to this concept, for example, instead of having the
Currently, this optimization in RxJS does not occur. Everything is in prototypes. This makes it possible to use the record of operators through the point, but the system cannot optimize the package size, since all the source code is considered to be used, even if it is not actually used in a particular project.
I hope that as RxJS becomes more accessible, and due to the fact that it is becoming easier to integrate into various projects, it will become more common among front-end developers. Now widespread RxJS prevent two obstacles. The first is the difficulty of learning. The second is the size of the library. RxJS has existed for a long time, but before the main development team was difficult to understand how to present it to programmers in a simple and understandable way.
The creators of Rx are great people, but they use complex terminology, which has led to a lack of attention to the project from the developer community. However, thanks to educational resources like This Dot, there is now an increase in interest in this wonderful tool.
In order to further spread RxJS, I am currently working on reducing the size of the library. Stay tuned for Tiny Rx, or T-Rx. In a nutshell, this project reduced the 24-kilobyte (compressed g-zip) library to just 3 KB!
It is nice to see how the popularity of RxJS is growing, how more and more programmers use it. In addition, I must say that everyone can join RxJS, make a contribution to the development of this powerful and useful tool.
If you’d like to learn more about RxJS, you’d like to learn more, here are some useful links: Rx Workshop , Intro to Rx , Thinking Reactively and RxJS in Depth .
Dear readers! Do you use RxJS in your projects?
In the vast world of front-end development, there are many interesting tools. I strive to find the right approach to the study of practical things, so I decided to talk with one of the most prominent representatives of the RxJS community, Ben Leshem. I wanted to learn more about RxJS, and why I, a novice developer, should invest time in learning reactive programming. In addition, I wanted to understand - why use RxJS in my projects. Ben told me about how to use RxJS and shared tips on learning this technology.
What problem does RxJS solve?
Programming is always a solution to problems and a search for tools suitable for finding answers to specific questions. In the case of RxJS, the problem to be solved is the ability to handle asynchronous calls using a variety of events. It is worth to dwell on this.
')
Imagine that you are writing a function that performs a certain sequence of actions with the data and that an error occurs during this work. If you simply use functions to process sequences of requests, there may be some optional actions taken to return an error. Instead of passing the error through all the functions, you need to be able to take the error and update the view without having to go through all the Ajax requests that are no longer needed.
You may notice that promises are created for organizing error handling in this style, but RxJS takes the concept of working with sequential actions to a new level. Promis can handle only a single value, which limits the use of this design. In addition, the promise cannot be canceled, which means that it can easily block the flow and waste resources (an important consideration for low-power devices).
In contrast, RxJS provides a way to eliminate these constraints by giving several communication channels, which simplifies the processing of multi-step events and increases its efficiency. RxJS, in addition, gives the developer the opportunity to consistently represent everything that needs to generate events. When everything looks the same, it turns out that it is very easy to work with all of this: to combine, combine, execute queries. All this makes RxJS a very powerful tool.
Why study RxJS?
On the one hand, RxJS is a powerful tool that allows you to turn complex sequences of actions into concise code that is easy to work with.
On the other hand, this simplicity is based on a variety of linguistic mechanisms, and their study takes time. However, the knowledge gained is worth the effort, when you realize that with a single line of code you can do something like an implementation of the drag-and-drop mechanism, which requires three sets of events.
This makes it possible to tie these events together (pressing the mouse button, moving the mouse, releasing the button) in order to get one short and precise line of code. With the usual approach, this requires a program of several dozen lines.
What are the benefits of using RxJS?
One of the most attractive opportunities when integrating RxJS into code is that the more you use it, the more you can do with this technology. RxJS can be compared to Lego, in the sense that Lego is great for developing new designs, since all cubes have the same shape. Similarly, all the observed objects look the same, so creating something with their use becomes a fascinating task, since you can experiment with a lot of interesting solutions. The more someone uses observable objects in the code, the more opportunities they get in creating something new based on existing structures.
What is the process of integrating observed objects into a large code base?
Observed objects can be used in almost any application. If we are talking about team development, it may take some time, however, the transition can be simplified if the following conditions are met:
- Work begins with the use of observable objects that are simple and expedient;
- Changes are well commented;
- Each member of the team is conveyed the meaning of the actions performed;
Everyone masters these things at their own pace, but in the end, don't be surprised if you find that your team does everything with Rx. When observed objects are used to perform certain actions, they all look the same and they are much more interesting to use when more and more similar objects appear in the application.
Are there any situations in which the use of observed objects is not recommended?
Of course there are! If we have a separate event that performs a single action, as often happens in JS programming, then using RxJS is a little weird. Of course, here you can apply RxJS, but it will be an obvious search.
The implementation of the drag-and-drop operation is an excellent example of a problem for which RxJS is ideally suited. This is an event with a multitude of actions, the complexity of which, with such an opportunity, is always useful to reduce.
How to understand when to use observable objects?
It is useful, when deciding whether to use observable objects, to rely on context. For example:
- If an action causes multiple events, use RxJS;
- If there are a lot of asynchronous operations and you are trying to establish their joint work, RxJS is also useful here;
- If you are processing huge datasets in arrays and you need to step through this data, you can use RxJS operators as something like transducers when they process these datasets without creating intermediate arrays, which you have to destroy later with a garbage collector.
Where should you start by deciding to explore the Rx operators?
The list of operators to start with should include
map , filter and scan . Other important operators include the following:switchMapconcatshare / shareReplay
You can narrow the list of used operators to less than ten of those that are required most often. There are, of course, operators to experiment with, like
pairwise , bufferCount and groupBy . These mysterious operators do not just exist, but they are not used very often. However, in those rare cases when you need to perform the actions implemented by these operators, you will not have to think about how to create them yourself.Is it easy to start using RxJS when working with a framework like React?
The use of RxJS in React is very similar to its use in Angular, where it is fully implemented. In Angular, the observed objects are the full entities of the system, hence the particular simplicity of using this technology in Angular. However, it is no more difficult than subscribing to RxJS in
componentDidMoun t and unsubscribing in componentWillUnmount . At the core of all this is the same idea as in Angular, the only difference is that these mechanisms are built into Angular, and in React you will have to implement everything manually.Can you share any tips on debugging Rx?
As with any other technology, in the course of studying Rx, debugging is simplified as the experience accumulates. There are some situations that are difficult to debug. I am currently working with the Chrome development team to solve these problems.
A typical difficult situation that programmers encounter occurs when they return something from a
mergeMap and expect to receive an observable object, but it turns out that this is not an observable object. Then they want to be able to see a function that returned what they thought was supposed to be an observable object, but it wasn’t. Currently, there is no way to show this, since it is impossible to know exactly what will be returned until the moment of return.Here are some debugging tips:
- Don't skimp on
console.log()calls; - Include the operator
doin the chain of observed objects, which will give an opportunity to see the state of the observed object at different steps, and what it returns.
What can you say about the future of RxJS?
RxJS is expected to see several changes that are worth paying attention to. So, the so-called “lettable” operators will be available soon. Thanks to this concept, for example, instead of having the
map operator in the observed object itself, there will be a map function, which, when called, returns another function. This function will then use the observed object to perform the same actions that were performed using its own operator. For example, instead of writing something like observable.map.filter.scan , you can write observable.compose(map, filter, scan) . This is a very serious and useful change, since when there are functions for creating other functions, many functional programming possibilities open up. Another improvement related to this improvement is the elimination of unused code when building packages (tree shaking).Currently, this optimization in RxJS does not occur. Everything is in prototypes. This makes it possible to use the record of operators through the point, but the system cannot optimize the package size, since all the source code is considered to be used, even if it is not actually used in a particular project.
How does the growing popularity of RxJS affect React and Angular?
I hope that as RxJS becomes more accessible, and due to the fact that it is becoming easier to integrate into various projects, it will become more common among front-end developers. Now widespread RxJS prevent two obstacles. The first is the difficulty of learning. The second is the size of the library. RxJS has existed for a long time, but before the main development team was difficult to understand how to present it to programmers in a simple and understandable way.
The creators of Rx are great people, but they use complex terminology, which has led to a lack of attention to the project from the developer community. However, thanks to educational resources like This Dot, there is now an increase in interest in this wonderful tool.
In order to further spread RxJS, I am currently working on reducing the size of the library. Stay tuned for Tiny Rx, or T-Rx. In a nutshell, this project reduced the 24-kilobyte (compressed g-zip) library to just 3 KB!
It is nice to see how the popularity of RxJS is growing, how more and more programmers use it. In addition, I must say that everyone can join RxJS, make a contribution to the development of this powerful and useful tool.
If you’d like to learn more about RxJS, you’d like to learn more, here are some useful links: Rx Workshop , Intro to Rx , Thinking Reactively and RxJS in Depth .
Dear readers! Do you use RxJS in your projects?
Source: https://habr.com/ru/post/341880/
All Articles