ng-conf 2014

Usando Promises en AngularJS

Christian Lilley  · 




Extracto de la transcripción automática del vídeo realizada por YouTube.

okay you got me you got me okay cool thank you my only personal note so it's 20 minutes go go go so my only personal note is I work at the Kinsey digital labs which is part of McKinsey and company and it's kind of like a startup accelerator for we

use open web technology for enterprises it's like the best of both worlds a cool place to work a hack on JavaScript all day and we're always looking for great people worldwide regardless of location all right we're gonna move really fast but if

you want to go in-depth I've got some training slides on my blog if you're at ng-conf chances are you've at least seen promises there are those weird things that you have to extract your data from when they come out of dollar HTTP right so why

do they exist if you've heard of them you've probably heard that they're about async which is true but that significantly understates their overall usefulness really they're designed in a way that lets them be about the bigger more general

idea of uncertainty about being able to crystallize uncertainty about time about space about user based issues and almost anything into a nice neat package put a bow on it and give it a super useful API that provides us with this gorgeous interaction pattern

so you can reason about and make decisions about uncertainty throughout your application and they're about helping you try to make the most of your brain when dealing with uncertainty promises make engineer brains work better zombie approved okay so even

though promises are about way more than async the truth is that it is what justifies their existence in the first place so let's talk a sink in the beginning was the word and the word was called back and the call back was man call backs have strengths

look they do the job they make a non-blocking i/o possible in the first place and everybody knows how to use them but they don't scale they lead us towards huge monolithic handler functions that try to do everything all at once and an attitude towards

async that it's something that you want to simplify and do it as little love as possible and just get it out of the way so that you can go back to doing synchronous predictable easily model of all kind of stuff so when you start trying to stack a complex

operation with callbacks things get ugly and nested and complex and unreadable really quickly we haven't even put anything into these handler functions yet right and they're already a mess see this shape forming here on the left you know what the shape

is called it's the pyramid of Doom we need to do everything right now in the pyramid of Doom because in a second all of our all of our data is going to be gone forget about coming back and picking up later where you left off and forget about that code

being intuitive and readable and clear and maintainable and if you do invade the pyramid of Doom and try to implement something that does let you leave off the middle of the pyramid and come back later you're gonna start building boilerplate like this

to catch state variables and outputs and add either timers or events so that you can trigger downstream actions later it's a mess it works but it can work but good luck with interoperation with other modules you didn't write good luck with passing

sequenced instructions back and forth between your scopes let alone the ones that don't even exist yet like controllers that aren't up and can't listen for events and then try doing that with all four of the tasks from that pyramid of doom that

I just showed you and you get this and mind you all of this junk doesn't even include any error or success handlers yet this is just what you have to have to be able to talk reasonably about whether these four async functions have fired yet whether they've

returned yet and whether you can do anything useful with their output yet and none of this code is actually doing anything it's just a bunch of imperative style housekeeping that's hard to keep track of and maintain and even harder to reason about

[ ... ]

Nota: se han omitido las otras 1.968 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.