Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

J S A S Y N C • Callbacks • Callback hell • Promises • Generators • Async / Await

Slide 6

Slide 6 text

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 ?

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Observable

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

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.

Slide 18

Slide 18 text

O B S E R VA B L E O F O B S E R VA B L E S … ?

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

H O T V S C O L D

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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)

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

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 .

Slide 29

Slide 29 text

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 .

Slide 30

Slide 30 text

LOL NO

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

E R R O R S ? • Still gotta catch ‘em all • Ever had promises swallow your errors? Yeah, observables will do that too • #SorryNotSorry

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

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.

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

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)

Slide 40

Slide 40 text

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.

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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 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); }

Slide 43

Slide 43 text

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.

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

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.

Slide 47

Slide 47 text

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: http://www.2ality.com/2015/11/tc39-process.html

Slide 48

Slide 48 text

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: http://www.2ality.com/2015/11/tc39-process.html

Slide 49

Slide 49 text

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: http://www.2ality.com/2015/11/tc39-process.html

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

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 • reacticex.io

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

@ H O LT B T