AngularJS Tutorial - Part 19 - Going Postal with Angular in Promises - NG-Conf Video Lecture - IT & Software

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 and extend so promises
let's be clear first promises are not a
technical innovation in the JavaScript
execution engine they don't make
anything happen more quickly they don't
execute async operations with different
native code they're all about the brains
of program
it's the same reason we do automated
testing and TDD and talk about
principles like single responsibility
and least surprise the promise pattern
is about making engineers more efficient
enabling you enabling us to reason about
async sensibly it allows us to look at
async stuff visualize it and uncertain
stuff in general visualize it and write
efficient code as if it were predictable
consecutive synchronous operations and
to link those operations together into
virtuous cycles or flows so if all
that's true the naive understanding of
promises needs to go out the door
promises are not simply syntax
replacement for callbacks there wouldn't
be any point in promises if that's all
they did used right promises are a
qualitative change a fundamental shift
in how we compose and plan for
uncertainty and sequencing so how about
an example how about if instead of all
that boilerplate I just showed you what
if you could just declare what you want
to have happen that you want a bunch of
uncertain things to happen in a certain
sequence based upon some other things
that are themselves uncertain how about
that
welcome to declarative async and
uncertainty with promises instead of you
writing all this boilerplate just
sequence for async operations across
your application and be able to come
back and interact with them later all
you need is this this is how the promise
pattern sequences things and provides
self awareness about what's going on it
knows when it's allowed to move forward
between steps it keeps everything in
order and it can be decomposed we can
decompose that chain of operations I
just showed you incredibly easily just
by showing storing references to the
promises for each stage of the sequence
the promises are the variables on the
left these actions will fire in the same
order as the previous simpler example
but now we can start inserting
additional actions later whenever and
wherever we want from any point in the
middle of this sequence
using the data that comes out of those
operations it's like having DVR for your
async operations we can even pass those
references in addition to going back and
grabbing them later and doing what we
want with them we can even pass them
into other contexts of your applications
and this is critical
without those contexts needing to know
anything at all about the process that
generated the promise because promises
are themselves an API that abstract Sall
of that away and if you need parallelism
if you want to have the three of our
four operations run in parallel instead
of in sequence and then have the fourth
one kick in only when all three are done
this is all you need okay either you
write all of the imperative boilerplate
from before and state variables and
other junk and then set a timer to check
every few milliseconds to see if they're
all done yet or use events if you're
lucky and that even works for you all
that or you do this one line that
replaces it all
that's composition with promises that's
the pattern they allow you to work with
them so if that's the overall pattern
what in a nutshell
are the component promise objects
themselves I promised a certain metaphor
in my talk title even though I'm not
going to do all the details here but at
root understand that a promise is
basically just a mailbox it's a special
standardized repository where you can
stash the data that outputs from an
operation it has a property representing
the completion and success state of that
operation and it has utilities that
leverage all that knowledge into further
downstream operations whenever you want
and all your functions everywhere can
have a key to this mailbox can and can
know what they need to about it so that
they can know what's going on and you
can even pick this mailbox up and carry
it around with you by reference into
different context of your application
providing your components with all the
benefits of async but without them
needing to understand the implementation
then on top of the promise there's this
thing called the deferred lots of folks
get promises and they're like yeah but
the deferred I'm not so sure it's really
straightforward
once you think of the promise as the
mailbox the deferred then is simply the
postman no no not that
endless tribute to Kevin Costner's
vanity thank God but just a real live
actual postal worker the postman is the
only one who's allowed to assign you a
new Pio box or create the promise or put
new packages into the PIO box
thus resolving the promise or inverting
the real-life example a little let's
pretend the little flag on the side of
the mailbox means you have mail it's
ready to pick up instead of that you're
sending mail out the postman would be
the one who'd be allowed to raise that
little flag showing you that you're
ready to go you have mail come get it
and do something with it
so with the deferred you're the postman
you can create and administer the
mailbox without the deferred you're a
customer a promise consumer that's it
that's the main idea but the pattern of
use is more significant than the
individual promise objects themselves
alone they are in a way just syntactic
sugar but together they can change your
whole approach to composition and they
can sure as hell reduce the amount of
boilerplate code you write guaranteed so
now remember promises are not just for
async time and place uncertainty is
certainly the conventional context for
promises but there are other kinds
especially user related a given Ajax
request is actually semi predictable
within a range users though are totally
unpredictable
you have no idea when or if your user
will get around to doing certain things
or in what order so take advantage of
promises as a way to encapsulate and
abstract that kind of sequencing as well
even though it's not execution engine
asynchronous Nasreen that term using
promises you can build custom async
interfaces that are api driven that are
totally understandable to all consumers
around user uncertainty as well as any
other kind which gets us finally to
angular angular is an example of what
happens when you start thinking in
promises structurally when you bake them
right into the fabric of the application
and use them as a way to model process
flows and to make sure that the right
things happen in the right order at the
right time so the different parts of
your application can handoff those flows
seamlessly and customize them and so
that you can think about them and so if
you think that music oh and vojta an
Igor and Brian and Brad and all the
other cats on the angular team are
pretty smart if you're here in other
words then follow their example and get
way into promises because angular is way
in the promises so here's sort of an
eight step program to using promises and
angular step one when you get started
with promises you're just a consumer
okay you're grabbing them from the
built-in services that return promises
like dollar HTTP and very notably dollar
timeout and dollar interval and I'm
going to stop using the dollar angular
has gone to the trouble to make all of
the most fundamental async functions
into promise generators so that promises
can be the seamless common API there's
that word again
an API for all of your async it's as
simple as this if if HTTP returns a
promise all you have to do is store a
reference to it forever after as long as
you hold the reference you can run other
operations against it
step two when you're ready to get a
little tricky try dollar resource ok the
implementation of resource has shifted a
little recently but here's the skinny on
1.2 and after resource works a little
differently than HTTP it's its promise
generating but it's it's a useful but
perhaps confusing pattern dollar HTTP
GET returns a simple promise but calling
the initial get method on a resource
type that you've defined returns a
resource object that resource object has
a promise it's not a promise it has a
promise as a property so to chain from
that resource with then you just use
resource object dot promise and then you
can do all the other same stuff with it
that you would with just a plain old
regular promise the weird cool thing
about is that the reference is circular
if you unwrap a resources
on this property which you get back from
inside of it is the original resource
which of course has a promise which you
can unwrap so the resource has a promise
which has a resource which has a promise
truly it's Turtles all the way down
complicating things further the other
instance methods on a resource like save
they don't modify that original promise
instead they return new bear promises
for the state of the individual
operations rather than modifying the
resource itself so step three is such a
big worthwhile feature that one of the
release candidates for the version of
angular it debuted and was named promise
resolution by using the resolve property
in your route definition you get several
huge benefits that you just don't want
to be operating without number one the
route won't change until your data has
been obtained and you have everything
you need in order to render the view no
flicker nothing looks broken that's it
it all just works and so your controller
number two gets to be totally completely
ignorant of all of the implementation
details it doesn't even need to know
what a promise is it doesn't need to
know how to unwrap it or how to check
the success of the operation route
provider does all of that for you all
the controller gets is whenever the
second is born it gets this data object
that's finished that's ready to go
inject it at creation time so it gets to
be totally implementation independent
which is the holy grail for controllers
whenever possible and so then in the
controller all you have to do is inject
the name of the property my data in this
case and you can do whatever you want
with it like bind it to the scope step
for this just be aware that it's
something related to what I just showed
you in angular 1.2 this changed for
awhile there you could place a promise
object on the scope and then angular
would automatically extract the value
from it and inject that into the view
you will see that in old documentation
beware of it it doesn't work anymore
okay reading the repo it seems it was
just too much magic for people it made
consumers of promises less aware of how
they worked and
to use them it complicated at using
parse it was also slow so just know that
it used to be there it's not anymore
don't trip over it and inject your
promises via resolve instead or just
unwrap them unwrapping is easy step five
start creating your own promises with
cue not just necessarily about
traditional async but about the other
stuff we talked about user uncertainty
any other question that you need to know
the answer to before you move forward if
it doesn't boil down into a nice handy
convenient boolean and sometimes even if
it does try wrapping it in a promise and
see if that doesn't make it easier to
proceed
check out those detailed slides I
mentioned for more details on how to do
that the third-party library is step 6
starting noticing how many third-party
implementations like UI bootstrap modal
also take advantage of promised flows in
very very virtuous ways if you define
one of these modal instances which
carries a promise as soon as it's
created you immediately define a handler
with modal instance dot result dot then
down here at the bottom before we've
even had time to do anything in that
modal before all that user uncertainty
kicks in we've already created a handler
for whatever we're eventually going to
return from the modal dialog as the
result object we don't know when or even
if there will be a return but we're
ready for it we can reason about it and
we can easily then just take that whole
thing after somebody's done and pass it
off into other contexts to other
consumers and let them deal with it as
they want
note that UI modal also uses a copy of
the angular resolve property just like
the angular router does to ensure that
the view in that modal won't be rendered
until the data is ready step 7
promises that you can reference without
needing to care if they even exist yet
let alone if they've resolved normally
you need to know that a promise has at
least been instantiated before you can
start interacting with it otherwise you
get undefined but because angular
services are instantiated lazily as
needed and persist throughout the
application lifecycle all you have to do
is wrap a service around that promise
and then it you can reference at any
time from any location provided you
simply
inject the service into that context of
controller let's say the caller of the
promise the controller need not know or
care anything about the implementation
or when that promise gets built now
outside of angular if you want to do
this or if you want multiple promises
inside one service you can do the same
thing with just a simple getter function
okay step eight is master level HTTP
interceptors there are these awesome
things that allow you to mess around
with every single Ajax operation that
goes in or out the door all from a
single location and their promised based
in both directions in and out requests
in response promises again aren't just
something for async output they're part
of the modeling of the whole cycle from
the beginning and thus you can chain
from even before an async operation
kicks off so this example is stripped
bare and oversimplified just so it fits
on screen it shows a way to trigger
automatic Universal loader screens in
your app whenever something any sync is
going on with promises we're able to
interact with the stream of low-level
instructions angular uses in the down in
the plumbing and we can even
conveniently pause the stream while we
wait for something to happen simply by
returning a promise that isn't resolved
yet you want to do validation you want
to check that a user session is still
open before you then issue the request
no problem
compose and insert a single promise
object in the right state and you get
that control right in the guts of
angular's operations we're gonna skip
this four time best practices use
service-oriented architecture think of
promises as the beginning of your
lifecycle or the flow and decompose your
handler functions and if you thought
perhaps the promises or this wacky thing
that's just out there that you don't
really have to use previously promises
were a library feature now native
promises in the browser are not only in
the Ekman scripts six spec they're in
release in chrome 32 as of this week
okay yeah
thank you guys anyone who's here at
anything to do that it's a little
different than the A+ spec but I think
in a good way so this means that
whatever the other browsers do even if
they lag we can rally around the
we can start getting used to it we can
shim it and you can make this API for
uncertainty that you can count on and
work into your stuff oh and the new Dom
API is are even going to return anything
async that comes from this point on as I
understand it will return a promise you
will have to deal with them thank you
very much I'm at about me slash XML
Thanks