From Callback Hell To Promises Heaven

Transcript

1. From callback hell
   to promises heaven
   

   View Slide

2. View Slide

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)
   

   View Slide

4. What is callback hell?
   

   View Slide

5. We’re used to thinking about this...
   

   View Slide

6. But callback hell is much
   more than that...
   

   View Slide

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)
   

   View Slide

8. View Slide

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

   View Slide

10. View Slide

11. View Slide

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
    

    View Slide

13. View Slide

14. Solutions?
    Enter promises...
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

18. View Slide

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?
    

    View Slide

20. View Slide

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

    View Slide

22. View Slide

23. View Slide

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
    

    View Slide

25. View Slide

26. View Slide

27. View Slide

28. View Slide

29. View Slide

30. Always use catch()!
    

    View Slide

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)
    

    View Slide

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)
    

    View Slide

33. Keep on smiling because you are the
    most beautiful people when you do!
    - Reign
    

    View Slide

34. Thank you!
    @r31gN_
    

    View Slide