There are a lot of interesting tools and resources to pick and choose from in this vast world of frontend development. In an effort to curate a powerful and practical direction with my learning, I sat down with one of the most prominent figures in the RxJS community, Ben Lesh, to learn more about RxJS and why it would be a good investment of time, as a junior developer, to learn and incorporate it into my code.
He walked me through ways I can apply RxJS and tips on how to go about learning it.
Q: What is the problem that RxJS solves?
A: Coding is all about problem solving and finding the right tools to fix the right problems. In the case of RxJS, the problem being solved is the ability to handle asynchronous calls with multiple events. But what does that mean exactly?
Imagine that you are writing a function that carries data along a series of actions and there is an error. If you are just using functions to handle the series of requests, there may be some unnecessary steps that are taken to return the error. Rather than passing the error through all of the functions, it should be able to take the error and update the view without running through the now unnecessary Ajax requests.
You may note that promises are made to solve this type of error handling, but RxJS takes the concept of funneling consecutive actions to the next level. A promise can only handle a single value, limiting it use cases. Additionally, promises are not cancellable, meaning that it has the potential to block the thread and use up unnecessary resources (important consideration for resource constrained devices).
Conversely, RxJS offers a solution to these limitations by offering more than one channel of communication to simplify the handling of a multi-step event in an efficient way. RxJS also provides developers the ability to treat anything that needs to fire an event as a single shaped thing. When everything is the same shape, it becomes very easy to combine and merge and query those things resulting in a very powerful tool.
Q: Why learn RxJS?
A: On the upside, it is a powerful tool that turns complicated series of actions into concise code that is easy to manipulate. On the downside, there is a lot of language involved that requires a bit of time to learn. However, it is worth it when you realize that with one line of code, you can do something like build a drag and drop which takes three sets of events and coordinates them together (mouse down, mouse movement, mouse up) to make one concise line of code. Which would otherwise be a few dozen lines of code.
Q: What are the perks of using RxJS?
A: One of the most attractive features of integrating RxJS into your code base is that the more you use it, the more you can do with it. RxJS is analogous to using Legos in the sense that Legos are great for inventive construction because all the nobs are the same shape. Similarly, all observables take the same form so building with observables becomes an enticing proposition because you can entertain many creative solutions. The more one uses observables throughout a code base, the more options you have to build upon existing structures.
Q: What would it look like if one wanted to integrate observables into a large codebase?
A: You can use observables in pretty much any application. It might take a bit of time to adjust as a team but if you:
-Start with applications of observables that are simple and appropriate -Comment the action well -Are willing to work with your team to educate everyone on what you are doing
It should be a smooth and helpful step for your team. It might take some time for everyone to learn it on their own, but don’t be surprised if you see your team start to “Rx everything”. When actions use observables, they all take the same shape and it becomes more exciting to use as it becomes more ubiquitous throughout your app.
Q: Is it ever not a good idea to use observables?
A: Sure! If it’s a single event and it’s doing a single thing, like a lot of JavaScript programming is, then RxJS is a little silly -– you can use it, but it would be overkill.
A drag and drop is a perfect example of when you would use it. It is an event with multiple actions that call for a reduction in complexity when possible.
Q: How can you tell when you should use Observables?
A: It is helpful to qualify when to use observables by context. For example, -If your action triggering multiple events — use RxJS -If you have a lot of asynchrony and you are trying to compose it together — use RxJS -If you run into situations where you want to update something reactively — use RxJS -If you are handling huge sets of data in arrays and you need to process the sets of data in steps, you can use RxJS operators as a sort of transducer where it processes those sets of data without creating intermediate arrays that then need to be garbage collected later.
Q: Where should one start when diving into the plentiful world of Rx operators?
A: Your go-to list of operators should include map, filter, and scan. Other important operators would be: -switchMap -concat -share / shareReplay
You can narrow your use of operators to less than 10 most frequently needed operators. There are always the strange esoteric operators to play around with like pairwise, bufferCount and groupBuy. They exist for a reason, but you don’t use them very often. However, on the occasion that you do need to perform these functions, you don’t have to go through the headache of building it yourself.
Q: How easy is it to get started writing RxJS in a framework like React? A: It is very similar to implement RxJS in React as it is to implement in Angular where is has been fully adopted. In Angular, observables are first class citizens so there is a particular ease that comes with using it in Angular. However, it is as simple as subscribing to RxJS on ComponentDidMount and unsubscribing on ComponentWillUnmount. It is the same idea as when you implement in Angular if you were to implement it manually.
Q: Do you have any tips on debugging Rx?
A: Like anything, it becomes easier to debug as one learns more about it and becomes more comfortable using it. There are some situations that are difficult to debug. I’m currently working with the Chrome dev team to work out solution for these particular cases.
One common obstacle people run into is when you return something from a mergeMap and its expecting an observable, but it returns something that is not an observable, people want to be able to see the function that is returning what they thought was an observable but is not. Currently, there is no way to show that because you can’t know the form of what is being returned until after it has returned. The pro-tip for this case is to: -use a lot of console log -compose the do operator into the observable chain so that you can see where the observable is in each step and what is being returned.
Q: What is coming up in the Rx future?
A: There are a few changes to look forward to in the future of RxJS. Lettable operators will soon be introduced for public use. Instead of having operators where you have a map operator on an observable itself, you’ll be given a map function and when you call it, it returns another function that an observable will then use to do the exact same work. For example, rather than writing observable.map.filter.scan, you write observable.compose(map, filter, scan). This is a very powerful change because when you get functions building functions a lot of functional programming opportunities opens up. Another advantage associated with this change will be better tree shaking. Right now that isn’t happening with RxJS because everything is being stuck on a prototype so you can do the dot chaining. So it assumes your using it all even though you are not.
Q: How is the growing popularity of RxJS changing the landscape of React and Angular?
A: As RxJS becomes more accessible and easier to integrate, I hope it will become more ubiquitous throughout the frontend community. Currently the two biggest obstacles to using RxJS are the learning curve and the space it takes up. RxJS has been around for a long time but previously the core team found it very difficult to figure out how to get it into the hands of the programmer in an understandable way. The creators of Rx are brilliant but they use complicated terminology which has resulted in a lack of participation by the average developer. Thanks to an increased advocacy for learning resources such as This Dot, there has been a large uptick in developer adoption of this remarkable tool.
To further the ease of this adoption, I am currently working on reducing the size of the RxJS. You can look forward to news of Tiny Rx — or T-Rx which takes the 24k (g-zipped) library to just 3k!
It is very exciting to see the growing popularity and implementation of Rx across the community. While interest has increased, there is still a way to go before it becomes widely used in communities outside the valley. It will be interesting to be a part of this growth and development of such a powerful tool.
Now that you have dipped your toes into the possibilities provided by RxJS, if you are interested to learn more, check out more resources like Rx Workshop, Intro to Rx, Thinking Reactively, RxJs in Depth.
Interviewee Ben Lesh Software Engineer at Google RxJS 5+ Project Lead
Author Necoline Hubner React Apprentice at This Dot @necolinesan
