In a previous post we showed how to leverage Observables, and especially their strength of composability to ease complicated async tasks.
As a recap, we built a simple wikipedia search demo consisting of a
WikipediaService to query a JSONP API.
We also built an
App component that uses this service and applies some Rx gymnastics to tame the user input, prevent duplicate requests and deal with out-of-order responses.
Thinking ahead we can refactor our code even further and let our API design leverage from the power of Observables.
Observables = Promises + Events (in a way!)
In a way Observables may be seen as the clever child of Events and Promises. Promises are first class objects that encapsulate the state of an asynchronous operation. But they are for singular operations only. A request is such an operation. You invoke a method, kicking off some async task and get a first class object that eventually will get you to the result of the operation (ignoring error handling for now).
Events on the other hand are for async operations that can continue to emit new values for an infinite duration. But Unfortunately they are traditionally not represented in a format that matches the criteria of a first class object. You can’t just pass an event of clicks around that skips every third click for instance.
Well, with Observables you can. You get the power of first class objects but without the limitations of singularity.
In fact, in a modern .NET language such as F#, which embraces Observables all the way down, every
IEvent<T> inherits from
IObservable<T>. Angular also went down this path and made
Smart service, dumb component
With that in mind: wouldn’t it be actually nice if we could save the component from dealing with all these edge cases? What if we just make the debounce duration configureable but let the rest of the complexity be handled by our
To let code speak we can transform our
WikipediaService into this.
Notice that the service still exposes the previous api as
rawSearch and builds a more clever
search API on top of it.
This dramatically simplifies our
See what happened? We just wire together event streams like lego blocks!
You can play around with the plnkr right here. Enjoy!
Angular 2 Master Class in Helsinki
Learn Angular 2 in our upcoming public training!Join now
Get updates on new articles and trainings.
Join over 700 other developers who get our content first.
Model-driven Forms in Angular 2
Earlier this year we've talked about template-driven forms in Angular 2 and how they enable us to build sophisticated forms...
Cold vs Hot Observables
One of the most exciting topics around Angular 2 is its relationship to Observables. There's one particular area that is...
Routing in Angular 2 revisited
Routing is hard. If you've followed the development of Angular 2 the last couple of months, especially the router, you've...
Component-Relative Paths in Angular 2
Creating components in Angular 2 is awesome in so many ways. Developers should be careful, however, when using external component...
How to prevent name collisions in Angular 2 providers
Angular 2's dependency injection improved in many ways. It not only is more flexible when it comes to assembling dependencies...
Exploring Rx Operators: map
In two of our previous articles we already highlighted the importance of Observables in Angular 2. This is the first...