RxJS in Angular 2 1. Quick overview of progress on RxJS Next (now RxJS 5) 2. Comparing Promises with Observables, and talking about why Observables are a better choice for Single Page Applications, like those written with Angular 3. Show the anatomy of an Observable 4. Talk about what Operators are 5. Show an example of reconnecting a multiplexed Web Socket using Observables in Angular 2.

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

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

3. Ben Lesh
Senior UI Engineer
Edge Developer Experience

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

5. “RxJS Next”
is now
RxJS 5.0.0-alpha

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

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

8. 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

9. RxJS 5 operators are
4.3x faster on average

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

11. RxJS 4

12. RxJS 5

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

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

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

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

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

18. “RxJS is LoDash or Underscore for async.”

19. Angular 2 is using
RxJS 5 Observables
for async

20. Angular has traditionally
used Promises for async

21. 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.

22. 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.

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

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

25. 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)

26. … 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.*

27. So how do we go from
Promises to
Observables?

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

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

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

31. Creating Observables is
similar to creating
Promises

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

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

34. if the producer’s resource
allows cancellation,
we can handle that here
let o = new Observable(observer => {
const token = doAsyncThing((err, value) => {
if (err) {
observer.error(err);
} else {
observer.next(value);
observer.complete();
}
});
});
const token
return () => {
cancelAsyncThing(token);
};

35. when you call o.subscribe()
let o = new Observable(observer => {
const token = doAsyncThing((err, value) => {
if (err) {
observer.error(err);
} else {
observer.next(value);
observer.complete();
}
});
return () => {
cancelAsyncThing(token);
};
});
observer => {
const token = doAsyncThing((err, value) => {
if (err) {
observer.error(err);
} else {
observer.next(value);
observer.complete();
}
});
return () => {
};
});

36. when you call
subscription.unsubscribe()
let o = new Observable(observer => {
const token = doAsyncThing((err, value) => {
if (err) {
observer.error(err);
} else {
observer.next(value);
observer.complete();
}
});
return () => {
cancelAsyncThing(token);
};
});
return () => {
cancelAsyncThing(token);
};

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

38. 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

39. Error Handling in
Observables is also
similar to Promise

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

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

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

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

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

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

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

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

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

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

50. 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();

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

52. 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.

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

54. 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.

55. Array filter, map, reduce

56. Observable filter, map, reduce

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

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

59. splitting and grouping operators
• groupBy
• window
• partition

60. buffering strategy operators
• buffer
• throttle
• debounce
• sample

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

62. “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.

63. 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.

64. 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

65. Create an Observable
that wraps a WebSocket

66. It will create the WebSocket
when you subscribe()

67. It emits messages events
that arrive on the WebSocket

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

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

70. Create an Observable
that wraps our
Socket Observable

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

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

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

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

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

76. Example Time!

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

78. 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.

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