Promise not to use Promises: ES7 Observables

3994a1ac47c4a684d7378ef06c1571cd?s=47 Brian Holt
September 25, 2015

Promise not to use Promises: ES7 Observables

Presented at UtahJS 2015 and Fluent 2016
Disclaimer: a lot of the pictures were animated GIFs. That doesn't come through on SpeakerDeck


Brian Holt

September 25, 2015


  1. E S 7 O B S E R VA B

    L E S P R O M I S E T O N O T U S E P R O M I S E S @ H O LT B T E S 2 0 1 6 E S 2 0 1 7 java s cr ip t LOL
  2. E S ’ 1 6 F E AT U R

    E S • Array.prototype.includes • [‘a’, ‘b’, ‘c’].includes(‘a’) // true • Exponentiation Operator • 2 ** 4 // 16
  3. None
  4. None
  5. J S A S Y N C • Callbacks •

    Callback hell • Promises • Generators • Async / Await
  6. W H AT A R E O B S E

    R VA B L E S A N D O B S E R V E R S ?
  7. None
  8. O B S E R VA B L E •

    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
  9. O B S E R VA B L E •

    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
  10. Observable

  11. None
  12. O B S E R VA B L E •

    We can essentially treat them like arrays • We get to apply all our function-programming-fu to the resulting observable subscriptions
  13. S T O C K T I C K E

    R N F L X [ $ 9 5 . . . $ 9 6 . . . . . . $ 9 7 . $ 9 6 . . . . . $ 1 0 1 . .
  14. N F L X [ $ 9 5 . .

    . $ 9 6 . . . . . . $ 9 7 . $ 9 6 . . . . . $ 1 0 1 . . A D B E [ $ 8 5 . . . . . . . . . . . . . . . $ 8 6 . . . . . . . . $ 8 5 M S F T [ $ 4 4 . $ 4 5 . . . . . $ 4 4 . . . . . $ 4 5 . . . . $ 4 6 . . .
  15. W H AT C A N Y O U D

    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
  16. None
  17. E V E RY T H I N G B

    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.
  18. O B S E R VA B L E O

    F O B S E R VA B L E S … ?
  19. None
  20. None
  21. F U N C T I O N A L

    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
  22. H O T V S C O L D

  23. C O L D O B S E R VA

    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
  24. H O T O B S E R VA B

    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
  25. D I F F E R E N T K

    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)
  26. A N Y T H I N G Y O

    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.)
  27. None
  28. O K AY, S O C A N ’ T

    I J U S T U S E B O T H ? I M E A N , L O L , I T ’ S N O T L I K E W E U S E A R R AY S F O R E V E RY T H I N G .
  29. Y O U C O U L D . I

    T ’ S C A L L E D V E C T O R P R O G R A M M I N G .
  30. LOL NO

  31. A C A S E F O R O N

    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
  32. P R O M I S E S A R

    E J U S T O N E - O F F O B S E R VA B L E S
  33. None
  34. E R R O R S ? • Still gotta

    catch ‘em all • Ever had promises swallow your errors? Yeah, observables will do that too • #SorryNotSorry
  35. C O M B I N E A R R

    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
  36. None
  37. AT N E T F L I X • Promises

    are outlawed in the code. We actively ripped them out. • Observables top to bottom! From the backend to the middle-end to the frontend.
  38. None
  39. U S E O B S E R VA B

    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)
  40. T C 3 9 O B S E R VA

    B L E S TAT U S • TC39 Stage 1 • Looking good for ES7 / ES2016! Didn’t make it. • Not looking very promising on ES2017 either.
  41. C U R R E N T D I S

    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
  42. A S Y N C G E N E R

    AT O R S • From Yehuda Katz and Allen Wirfs-Brock (two super sharp guys.) • With an iterator, you call and get a result back. With async iterators, you call 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); }
  43. S O W H Y D I D N ’

    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.
  44. B U T D O N ’ T C A

    L L T H E M E S ’ 1 6 F E AT U R E S
  45. None
  46. J U S T C A L L T H

    E M F E AT U R E S • Rather than say “this is an ES’16 feature” call it a stage 0/1/2/3/4 feature. That’s the more interesting part anyway.
  47. T C 3 9 F E AT U R E

    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:
  48. T C 3 9 F E AT U R E

    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:
  49. T C 3 9 F E AT U R E

    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:
  50. None
  51. S H U T U P A N D TA

    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 •
  52. None
  53. @ H O LT B T