An introduction to RxJs Observables with latest AngularJs
If you have been working with angular 2 and you’ve been using the reactive approach a lot then you might be aware of the crazy world of Observables and its operators.
While working with observables what’s most astonishing is the overwhelming availability of observable operators. One should not start worrying about not being able to recall or use at a glance these operators, believe me, it takes time getting your head around Observables and these world of operators.
I think Observables can be explained very intuitively using the chart below.
In short, observables can be thought of as an evolution from Objects to arrays to promises and finally observables.
- Objects are good at returning a value.
- Promises are good at returning a value asynchronously.
- Arrays can return multiple values but again synchronously.
- Welcome Observables, they return multiple values asynchronously.
Promises die once they return a value, whereas observables continue to live even though they may have returned values. They keep returning values, and its in our control to set a rule as to when they die.
Disclaimer: I call it a rule internally at Aviabird and its not a standard term. A rule is nothing but how should an observable behave over time, for example, I can say create an observable using range(0, 10) this returns an array from 0 up to 10 numbers or I can say create an observable which listens to a click event on a button or I can say create an observable which hits the Wikipedia API and fetches some results. All these are nothing but Rules.
Let’s see an observable in action IMO this is the most basic example of observables.
Let’s look at line 1. It creates an observable which is only a rule. It doesn’t do anything really. It just states that observable for a range from 0 up to 10 numbers be created. Remember this doesn’t do anything as of yet, you must subscribe to it if you have to get anything out of an observable.
RULE OF THUMB: To get anything out of an observable(which is reactive nature) one has to subscribe to it.
That’s what we do on line 3 and then the value emitted from the observable can be caught inside of the subscribe method first callback. 2nd and 3rd are reserved for errors and completed states, we’ll come back to it later.
In the above example when we subscribe to the observable it just spits all the values at once, pretty straightforward. Next, let’s look at a little complex scenario.
In this example, we create an observable but we have not added any rule to it like in the previous example of range.
We are relying on an onNext function which does exactly the same. It tells the subscriber from within that something has changed inside of me, please pay attention and use the first callback to handle the data that I am sending to you.
Since I wanted to delay that a bit so I added a timeout which just delays the emission from the observable.
Now you must be thinking where could this be used in real world scenario. Imagine you are a celebrity who has a twitter profile. You just break the internet when you post something on twitter. What if for each like or retweet you got a push notification in the browser, wouldn’t it make your life very difficult if for each push notification you get a pop sound. Damn so many ding dongs.
Possible Observable solution: Keep listening to the notification observable and use a very cool operator called buffer operator which can take a buffer of 5 mins(not used in this example) or refresh notifications button and then summarize all the notifications in one notification. For ex. You’ve got 1.5 million likes since you last checked.
You can see it in action here.
Whenever you click on check new notifications button it checks and counts what are the new number of notifications since the last time the button was clicked by you and emits those new notifications.
In this time/stream diagram, buffer operator functionality is visualized and how it works.
Now I think after this example the observable pattern is a bit clear, believe me I have not even scratched the surface of what observables are capable of and I’d be writing a lot of blog posts on how many ways we can use observables to make our lives easier while working with complex cases in our day to day life.
I have explained observables, first part of the blog post is over continue if you want to learn about operators with observables.
AVIACOMMERCE: OPEN SOURCE E-COMMERCE
Aviacommerce is an open source e-commerce framework with an aim to simplify e-commerce ecosystem by creating and unifying smart services and providing consistent, cost-effective solution to sellers helping them sell more. visit aviacommerce.org to know more.
Operators: real power of observables
Observables are very powerful but real power of observables can only be harnessed when we use the right operators . For this purpose I am creating a small list of operators which are used the most. This list will keep growing over time.
Remember operators can be chained and each operator, in turn, returns an observable.
When you have a new hammer, everything looks like a needle, including screws.
So a word of caution you should know if you are using an operator what it does and whether it’s a good fit or not.
Apply certain logic to each element passed.
A very good example would be to convert data coming from backend to Json format.
When source emits, switch to and emit values emitted from latest inner observable, discards any other values which were a result of the previous source emission.
Consider Google search bar which fires requests after each key stroke now in this case lets say a user is typing very fast and writes 7 letters then there would be 7 backend requests for which there would be 7 corresponding responses, but we probably don’t care about the responses for the past requests but the final search term, switchMap fits right in here it discards all the other previous responses and just emits the response corresponding to the latest search requests.
When source emits, merges to previous values and emit values combined from latest inner observable, does not discard any other values which were a result of the previous source emission.
Consider you are building a platform which merges feeds from multiple apis then a possible way to represent that would be creating 2 observables for each API endpoint, now we don’t care about the time at which we get the response from both these observables, we want to finally merge them and show collectively. This is where flatMap comes into picture.
Classic web search example: FlatMap should be used when all results matter, regardless of their timing, and switchMap should be used when only results from the last Observable matter.
Kartik Jagdale recently wrote about
debounceTime operator. You can check it out in the link below.
If you liked this article, click the 💚 below. I notice each one and I’m grateful for them.
For more musings about programming, follow me so you’ll get notified when I write new posts.