Another way of dealing with async code • Similar to event emitter or publish/subscribe semantics you’ve seen • You can easily model pub/sub with observables
To simplify the definition, they are objects that can inform other objects of the changes they publish • Publishes can happen an indeterminate amount of times
O W I T H T H AT ? • .map() – Need to show the latest stock update to the UI • .concat() – Show each companies’ stock grouped together • .filter() – Show only quotes increasing in value over time • .reduce() – Show the average stock price amongst tech companies
E C O M E S O B S E R VA B L E • Mouse, touch , or setInterval events? Observable of events. • Polling? Observable of server responses. • Switch to web sockets? Anything observing those responses doesn’t need to change • Subscribing to an indeterminate amount of flux stores? Observable of observables of actions.
O P E R AT I O N S • .flatMap() - Flatten an observable of observables to a flat observable (think flatten array of arrays to an array) • .zip() – Chat client where a user has their comments ‘zipped’ to the user • .take() - Infinite sequence where you only want the first n numbers
B L E S • The tree won’t fall if no one is listening • Calling the method that returns the observable does nothing • Once subscribed, then the action actually happens • Think of a database call that doesn’t happen until someone is there to listen
L E S • The tree is going to fall even if no one is listening • The data is going to be retrieved even if no one is listening • Think mouse move events; that’s going on even if no one is listening
I N D S O F O B S E R VA B L E S • Normal observables – if you weren’t subscribed, you missed it. You start getting data as soon as you subscribe • Behavior observable – you essentially get the last value and all data going forward. Similar just to value that will update itself over time • Replay observable – keeps a cache of the past n values given and will give those to you as soon as you subscribe • Subject – Both an observer and an observable. You’ll be tempted to use these a lot when starting out. I’d say go for it. (normally you don’t use them much)
U C A N D O T O A N I T E R AT O R Y O U C A N D O T O A N O B S E R VA B L E • Really • Observables are the duals of iterators • Dual means the mathematical inverse • This is important because that proves anything you can do to an iterator (array) can be done to an observable (like .map, .filter, .reduce, etc.)
LY U S I N G O B S E R VA B L E S • You can treat anything async the same. • Compose all the AJAX calls! • Part of the power of both promises and observable is the composeability of them. • You can make it work but you’re constantly switching
AY S / I T E R A B L E S W I T H O B S E R VA B L E S ? • No prob • Observable.from will take any iterable (something you can call .next() on) and spit out observable magic
L E S I N Y O U R A P P S • Until observables land in JS natively, it’s presumptuous to make your modules use observables. • Promises fit public (npm) modules’ needs nicely. • However in your app dev, pull in RxJS (or BaconJS) and go crazy! (it’s easy to observablify modules)
C U S S I O N S AT T C 3 9 • Synchronous observables! Instead of waiting, if they have data, they just fire • Object.observe would return an observable (duh, right?) • Best of expressing the flexibility of observables without the massive amount of new methods and syntax (just look at how big the full RxJS is) • Cancellable promises? • Async iterators
AT O R S • From Yehuda Katz and Allen Wirfs-Brock (two super sharp guys.) • With an iterator, you call iterator.next() and get a result back. With async iterators, you call iterator.next() and you get a promise back. • They introduce some convenience structures for interacting with async iterators like async / await for-of loops. for await (let line of readLines(filePath)) { print(line); }
T W E M A K E I T F O R E S ’ 1 6 ? • The process for TC39 totally changed after ES6. Instead of monolith huge releases (like ES6) we moved to very small, incremental releases. If you miss the train, you have to wait for the next one. • “The train” leaves on March 1 every year. They take a snapshot of what proposals are in stage 4 (they have two browsers implementing the feature) and those get shipped as ES ’16. • The introduction async iterators muddied the waters a bit for generators.
P R O P O S A L S TA G E S • Stage 0 – Strawman Proposal • Must be submitted by a TC39 member or a registered nonmember. No implementation required; just a document describing the proposed feature • Stage 1 – Proposal • A formal document must be presented with the proposed API, edge cases, examples, everything; must exhaustively describe the feature in question. Polyfills and demos expected source: http://www.2ality.com/2015/11/tc39-process.html
P R O P O S A L S TA G E S • Stage 2 – Draft • Must have documentation as it will be presented in the ECMAScript spec document. Should be as complete as possible. At this point, including into ECMAScript is very likely. Two experimental implementations expected, but one can be a transpolar like Babel • Stage 3 – Candidate • Mostly finished by now. Needs developer testing. Must have two full implementations now (can be behind flags.) Spec no longer likely to change much source: http://www.2ality.com/2015/11/tc39-process.html
P R O P O S A L S TA G E S • Stage 4 – Finished • Feature is now a normal, totally accepted part of the language. Acceptance tests now expected (unit tests for the whole JS language.) Two spec complaint implementations required and significant testing of the feature from the users. source: http://www.2ality.com/2015/11/tc39-process.html
K E M Y M O N E Y T E A C H M E T H I S B L A C K M A G I C • Jafar Husain just put out a video course on Frontend Masters and it is spectacular. • learnrx book • reacticex.io
btholt
77web
nrslib
.jpeg){kind=avatar}
ostk0069
iwatatomoya
fabpot
sgash708
stoneream
syumai
kubotak
kotamanegi
ssssota
mkmk884
kneath
mclloyd
jonrohan
bkeepers
soudai
jlugia
tammyeverts
mza
maggiecrowley
tenderlove
thoeni
