Upgrade to Pro — share decks privately, control downloads, hide ads and more …

From Callback Hell To Promises Heaven

From Callback Hell To Promises Heaven

r31gN_

July 25, 2016
Tweet

More Decks by r31gN_

Other Decks in Technology

Transcript

  1. From callback hell to promises heaven

  2. None
  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)
  8. None
  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...
  10. None
  11. None
  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
  13. None
  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)
  18. None
  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?
  20. None
  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().
  22. None
  23. None
  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
  25. None
  26. None
  27. None
  28. None
  29. None
  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_