RxJS In-Depth - AngularConnect 2015

RxJS In-Depth
(Formerly a talk called
“Reactive Streams in Angular 1 and 2”)

We had a last-minute
pivot on talk content,
because Jeff Cross and
Rob Wormald wanted to
ruin my week last week.

Ben Lesh
Senior UI Engineer
Edge Developer Experience

RxJS Next
http://github.com/ReactiveX/RxJS

“RxJS Next”
is now
RxJS 5.0.0-alpha

RxJS 5 is community
driven
Spear-headed by contributors at Netflix, Google
and Microsoft. With many other contributors
under the ReactiveX community banner.

RxJS 5 Goals
• Performance
• Improved debugging
• ES7 observable spec alignment

Performance
• Decisions were guided by performance testing
• Tried out 4-5 different architectures in the
beginning
• > 120 micro performance tests
• ~ 10 macro performance tests around common
scenarios and bottlenecks

RxJS 5 operators are
4.3x faster on average

Call-stack depth and debugging
was a common complaint in older
versions of RxJS

Thanks in huge part to
contributions from
Paul Taylor OJ Kwon
André Staltz Jeff Cross

… really every one of our
contributors.
https://github.com/ReactiveX/RxJS/graphs/contributors

Thanks to guidance from
Matt Podwysocki Jafar Husain Erik Meijer
Ben Christensen George Campbell Aaron Tull

we’re closing in on beta
in the next month or so

What is RxJS?
• Reactive programming
• Treating events as collections
• Manipulating sets of events with ”operators”

“RxJS is LoDash or Underscore for async.”

Angular 2 is using
RxJS 5 Observables
for async

Angular has traditionally
used Promises for async

Promises
• Read-only view to a single future value
• Success and error semantics via .then()
• Not lazy. By the time you have a promise, it’s on
its way to being resolved.
• Immutable and uncancellable. Your promise will
resolve or reject, and only once.

Observable
• “Streams” or sets
• Of any number of things
• Over any amount of time
• Lazy. Observables will not generate values via an
underlying producer until they’re subscribed to.
• Can be “unsubscribed” from. This means the
underlying producer can be told to stop and even tear
down.

Both Promises and Observables
are built to solve problems
around async
(to avoid “callback hell”)

Types of async in modern
web applications
• DOM events
• Animations
• AJAX
• WebSockets
• SSE
• Alternative inputs (voice, joystick, etc)

Promises only really make
sense for one of these
• DOM events (0-N values)
• Animations (cancelable)
• AJAX (1 value)
• WebSockets (0-N values)
• SSE (0-N values)
• Alternative inputs (0-N values)

… except when they don’t
• Single page applications commonly prepare data
via AJAX for each view shown
• When the view changes, the next view probably
doesn’t care about the previous view’s data
• Fortunately, XHRs can be aborted!
• …but promise-based AJAX implementations
cannot be aborted, because promises cannot be
cancelled.*

So how do we go from
Promises to
Observables?

They have some similar
semantics
then x. (valueFn, errorFn);subscribe

They have some similar
semantics
x.subscribe(valueFn, errorFn);, completeFn

Observable also has
cancellation semantics!
let sub = x.subscribe(valueFn, errorFn, completeFn);
// ...some time later
sub.unsubscribe();

Creating Observables is
similar to creating
Promises

creating a Promise
let p = new Promise((resolve, reject) => {
doAsyncThing((err, value) => {
if (err) {
reject(err);
} else {
resolve(value);
}
});
});

creating an Observable
let o = new Observable(observer => {
doAsyncThing((err, value) => {
if (err) {
observer.error(err);
} else {
observer.next(value);
observer.complete();
}
});
});

if the producer’s resource
allows cancellation,
we can handle that here
const token = doAsyncThing((err, value) => {
if (err) {
} else {
}
});
});
const token
return () => {
cancelAsyncThing(token);
};

when you call o.subscribe()
if (err) {
} else {
}
});
return () => {
};
});
observer => {
if (err) {
} else {
}
});
return () => {
};
});

when you call
subscription.unsubscribe()
if (err) {
} else {
}
});
return () => {
};
});
return () => {
};

Don’t worry... you’re
unlikely to be creating
your own Observables

Observable creation
helpers in RxJS
• Observable.of(value, value2, value3, …)
• Observable.from(promise/iterable/observable)
• Observable.fromEvent(item, eventName)
• Angular’s HTTP and Realtime Data services
• Many community-driven RxJS modules and
libraries

Error Handling in
Observables is also
similar to Promise

catch
myPromise.catch(error => {
if (error instanceof OkayError) {
return Promise.resolve(‘okay’);
} else {
throw error;
}
});

catch
myObservable.catch(error => {
if (error instanceof OkayError) {
return Observable.of(‘okay’);
} else {
throw error;
}
});

finally
(some promise impls)
myPromise.finally(() => {
console.log(‘done’);
});

finally
myObservable.finally(() => {
console.log(‘done’);
});

Observables can be “retried”
myObservable.retry(3);
myObservable.retryWhen(errors =>
errors.delay(3000));

Quick Recap on
Observable
An observable is a set of any number of things over
any amount of time.

Quick Recap on
Observable
All values are pushed to the nextHandler
observable.subscribe(nextHandler);

Quick Recap on
Observable
The errorHandler is called if the producer
experiences an error
observable.subscribe(nextHandler, errorHandler);

Quick Recap on
Observable
The completionHandler is called when the producer
completes successfully
observable.subscribe(nextHandler, errorHandler, completionHandler);

Quick Recap on
Observable
Observables are lazy. It doesn’t start producing
data until subscribe() is called.
observable.subscribe(nextHandler, errorHandler, completionHandler);

Quick Recap on
Observable
subscribe() returns a subscription, on which a
consumer can call unsubscribe() to cancel the
subscription and tear down the producer
let sub = observable.subscribe(nextHandler, errorHandler, completionHandler);
sub.unsubscribe();

What are “operators”?
They’re methods on Observable that allow you to
compose new observables.

How operators work
let result = source.myOperator();
result is an Observable, that when subscribed to,
subscribes to source, then tranforms it’s values in
some way and emits them.

How operators work
subscription.unsubscribe();
when unsubscribe() is called on that
subscription, the unsubscription logic from both
result and source are called.

How operators work
• Operators pass each value from one operator to
the next, before proceeding to the next value in
the set.*
• This is different from array operators (think map
and filter) which will process the entire array at
each step.
• *This can be changed with Schedulers.

Observable filter, map, reduce

simple operators
• map()
• filter()
• reduce()
• first()
• last()
• single()
• elementAt()
• toArray()
• isEmpty()
• take()
• skip()
• startWith()
• and many more…

merging and joining operators
• merge
• mergeMap (flatMap)
• concat
• concatMap
• switch
• switchMap
• combineLatest
• withLatestFrom
• zip
• forkJoin
• expand

splitting and grouping operators
• groupBy
• window
• partition

buffering strategy operators
• buffer
• throttle
• debounce
• sample

With ES7 function bind,
you can roll your own*
(*coming soon to TypeScript?)

“hot” vs “cold” observables
• Observables are “cold” by default
• “Cold” observables create a new producer each
time a consumer subscribes to them
• “Hot” observables share a single producer with
every consumer that subscribes to them.

Multiplexed WebSocket
• Connect to a web socket server
• For each data stream
• send a subscription message to the server
• filter out responses from the server
• when done, send an unsubscription message.
• Ideally, the socket is only open while you require data
from it.

Multiplexed WebSocket
• RECONNECTION?!
• maintain a state of all of the multiplexed data
streams your views need.
• check to see when you’re able to reconnect
• reconnect the socket
• once the socket is reopened, send all of the
subscription messages again

Create an Observable
that wraps a WebSocket

It will create the WebSocket
when you subscribe()

It emits messages events
that arrive on the WebSocket

And when it unsubscribes,
it will tear down the WebSocket!

“Share” to make it “hot”…
We don’t want each subscription
creating it’s own websocket.

Create an Observable
that wraps our
Socket Observable

filter the messages
from the Socket Observable
to what you need
and subscribe

Send a message to
the server to start getting
the data over the socket

on unsubscribe,
tell the server
to stop sending data
and unsubscribe
from the socket observable

Add a retryWhen to retry the whole thing
if something goes wrong with the multiplexed observable

“share” the observable to make it “hot”,
so many consumers can share this producer.

Never trust anyone with
only good things to say
about their
library/framework.

What’s bad in RxJS?
• “Zalgo”.. don’t use mutable outer scoped
variables in your operators or subscriptions!
• Unbounded buffers! The zip operator in particular
is dangerous here.
• Too many operators to remember.

Twitter: @benlesh
github: blesh
ben@benlesh.com
GOOD: Comments.
BETTER: Questions.
BEST: Corrections!
Thank you!

RxJS In-Depth - AngularConnect 2015

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to RxJS In-Depth - AngularConnect 2015 (20)

Recently uploaded (20)

RxJS In-Depth - AngularConnect 2015

Editor's Notes