From Callback Hell To Promises Heaven

Transcript

1. From callback hell to promises heaven
3. Who’s that guy? • Name: Vlad Zelinschi • Nickname: Reign • Occupation: UI Tech Lead, Advanced Technology Group Member at 3PG • Real occupation: talks gibberish on Twitter (@r31gN_), scrolls Facebook all day, writes sloppy code at work and on GitHub (@r31gN)
4. What is callback hell?
5. We’re used to thinking about this...
6. But callback hell is much more than that...
7. Callbacks • Callback driven design is still the most popular pattern for async programming but it also applies in sync programming • But callbacks have shortcomings • They express something that’s in contradiction with the way our brains are used to thinking (which is a SEQUENTIAL PROCESS)
9. I need to go to the store, but on the way I'm sure I'll get a phone call, so 'Hi, Mom', and while she starts talking, I'll be looking up the store address on GPS, but that'll take a second to load, so I'll turn down the radio so I can hear Mom better, then I'll realize I forgot to put on a jacket and it's cold outside, but no matter, keep driving and talking to Mom, and then the seatbelt ding reminds me to buckle up, so 'Yes, Mom, I am wearing my seatbelt, I always do!'. Ah, finally the GPS got the directions, now...
12. Callback hell • It’s about “bouncing” through your code so you can understand what’s going on • The earlier example was overly simplified: think two or more chains of these callback continuations are happening simultaneously, or when one callback branches out into "parallel" callbacks with gates or latches, or… • PROBLEM: callbacks express asynchrony in code in ways our brains have to fight just to keep in sync with • PROBLEM: trust issues (IOC - Inversion Of Control); you give control to 3rd party that you didn’t write which is now responsible for continuation of your program
14. Solutions? Enter promises...
15. Real world example 1. Go to McDonald’s 2. Ask for Big Tasty 3. Pay, get receipt (a representation of a future Big Tasty) 4. While Big Tasty is being made, I can call my friend and ask him to join me for lunch (doing another action in the meantime) 5. Big Tasty’s creations was a success - I handle receipt, I get food 6. Big Tasty’s creations was a failure (no more cheese) - I'll have to figure out something else to eat for lunch
16. Promises • A representation in code of a future value • Like a proxy for a value not necessarily known when the promise is created. It allows you to associate handlers to an asynchronous action's eventual success value or failure reason • This lets asynchronous methods return values like synchronous methods and manipulate them via API • 3 states: pending, fulfilled, rejected • Aims to solve the trust issues of callbacks and provide a more synchronous representation of your code
17. Promises - solving trust issues • Promises, by definition, cannot be observed synchronously, so they will never be called too early (what you pass into .then() will always be async) • It's not possible for a synchronous chain of tasks to run in such a way to "delay" another callback from happening as expected. That is, when a Promise is resolved, all .then() registered callbacks on it will be called, in order, immediately at the next asynchronous opportunity (they can’t be called too late)
19. Promises - solving trust issues • Nothing can prevent a Promise from notifying you of its resolution (if it's resolved). If you register both fulfillment and rejection callbacks for a Promise, and the Promise gets resolved, one of the two callbacks will always be called (solved the concern of never calling the callback) • What if it hangs?
21. Promises - solving trust issues • Promise are implemented in such a way that they can only be resolved once, any then(..) registered callbacks will only ever be called once (each). This solves the concern of calling too few or too many times. • Promises guarantee a correct passing of any parameter or environment to all registered callbacks as long as you pass in an object to resolve() or reject(). • Promises also address the concern of swallowing errors - correctly user reject () and cath().
24. Promises - building blocks for async flow • Promises have a very well defined API, that can help us achieve different things: then, catch, race, all, resolve, reject, etc. • Every time you call then(..) on a Promise, it creates and returns a new Promise, which we can chain with • Whatever value you return from the then(..) call's fulfillment callback (the first parameter) is automatically set as the fulfillment of the chained Promise
30. Always use catch()!
31. Promises - limitations • Chaining promises means the catch() at the end will not be notified if any error handling was done along the way (this may be or may not be what you want) • Promises return a single value • Single resolution - they can only be resolved one (fulfilled or rejected). That why in certain cases (eg: event modeling reactions), streams are better • Noncancelable (Why?) • Slower than callbacks (though it’s pretty hard to determine how much slower)
32. Promises - review • USE THEM! • Solves IOC issues (they don't get rid of callbacks, they just redirect the orchestration of those callbacks to a trustable intermediary mechanism) • A better way of expressing async flow in sequential fashion (ME BREIN LIKES IT)
33. Keep on smiling because you are the most beautiful people when you do! - Reign
34. Thank you! @r31gN_