谷歌I/O 2013 - AngularJS中的設計決策 (Google I/O 2013 - Design Decisions in AngularJS)

Subtitles section Play video

MISKO HEVERY: Hi, my name is Misko Hevery.
I'm the father of AngularJS.
BRAD GREEN: And I'm Brad Green, and I will play
Angular's manager today.
It's what I do.
All right, so we wanted to take some time in front of you
folks-- thanks for coming, by the way-- talking about what
it is that drove us to build Angular.
Because we think, when people come and look at the Angular
framework, a lot of times they see the features of Angular,
and maybe we're not very clear about what we meant.
When they come to see the features, they see what we
call the three D's--
directives, dependency injection, and data-binding.
But we're passionate about some very different things.
We just happened to arrive at these features along the way.
So Misko, why don't you talk about what do you care the
most about web development?
MISKO HEVERY: So web development, if you think
about it, is all about getting data to the browser, and then
back to the database.
And so one of the things that you end up doing is a whole
lot of boilerplate marshaling of the data back and forth.
And after you build a couple of web applications, you're
just getting tired of writing the same thing
over and over again.
And it's kind of getting in the way of just building the
actual stuff.
And so, the boilerplate is one of the things that we really
wanted to eliminate as much as possible
inside of our codebase.
BRAD GREEN: Right.
So we thought that if we can distill our apps-- if we could
boil them down, maybe--
to their essence, about just what adds value to the app,
then it'd be very much--
it's easier to build these applications, but also easier
to understand.
We spend a lot more time reading code than writing it.
So we thought that would be cool.
MISKO HEVERY: So the next thing is, every single
application I've ever been on, it was structured
in some other way.
And having a common way of structuring the application
means the developer can easily bring--
come up to speed on your codebase, and we can easily
move between projects.
And so giving structure to the applications is another
important thing.
BRAD GREEN: What is that shape, Misko?
MISKO HEVERY: That's a scaffolding, sir.
BRAD GREEN: Do you know how to draw scaffolding?
MISKO HEVERY: No.
I do not get paid to draw.
I get paid to write code.
BRAD GREEN: OK, good thing.
Good thing.
MISKO HEVERY: And then lastly, I'm a big fan of testability,
and so we put a lot of testing effort into our framework.
But it's not enough to just build a framework
which itself is tested.
It's all about making sure that the people--
developers writing code, using the framework will have easy
time testing.
And so one of things we wanted to make sure is the way the
framework is structured naturally leads you down the
stability path
BRAD GREEN: That's right.
And we believe that if you're shipping software, you better
be shipping tested software.
So we really wanted to make that easy.
So let's go back to a few years to 2009, where I think I
said, Misko, you should go learn JavaScript.
This seems like the new thing.
And what did you do?
What was your first inclination as a newbie in the
world of JavaScript?
What did you do?
MISKO HEVERY: Well, write a framework.
What else would you do?
BRAD GREEN: That's right, every newbie
should write a framework.
It's a good policy.
MISKO HEVERY: So the idea behind Angular-- the original
Angular was actually a little different, which was that
there's a lot of web designers out there, people who are not
really programmers, developers per se, but they know how to
put HTML together because it's so declarative, and
it's easy to do.
And so, could we enable the web designers to be able to
build a very trivial, simple application just by a dropping
little bit of extra markup logic into the HTML?
So you don't even have to manage your backend.
You have some database in the cloud, and you include the
script tag, put a little bit of extra tags, and all of a
sudden, your form becomes persistable form and can send
email, and things of that sort.
BRAD GREEN: That's right.
You know, this eye-stabbingly yellow logo, right?
MISKO HEVERY: You have something against yellow?
BRAD GREEN: I got better.
MISKO HEVERY: All right.
BRAD GREEN: All right, so fast forward just a little bit to--
we were on a project together.
And I remember Misko-- this was a project
called Google Feedback.
And Misko, you and the other developers on the project were
kind of unhappy with our development pace?
MISKO HEVERY: Yes.
The velocity was not so great.
We spent about six months, three of us working on this
particular project.
17,000 lines of code later, we were really not making the
progress we wanted to make.
And so we're frustrated.
And so in my frustration, I went to Brad, and I said, you
know, Brad, I'm working on this thing in my free time,
kind of an open source project.
And I bet you I could rewrite the whole thing in two weeks.
BRAD GREEN: And I said, go for it, because two weeks--
whatever.
But I don't think you quite made it in two weeks.
MISKO HEVERY: No, I didn't make it in two weeks.
It took me three weeks.
And 1,500 lines of code later, we actually have rewritten the
whole application.
BRAD GREEN: I was impressed.
And this was kind of the start where I though, well, Angular
seems like it could be a thing unto itself, not just a part
of Google Feedback as the way it was.
And this is where we decided we would spin it off into its
own entity.
MISKO HEVERY: So what exactly is it to build a single-page
application?
Well, you have a database, and you the browser, and the stuff
in the middle is really what we're talking about, right?
And so to have a single-page application is really all
about modifying the DOM-- you know, the divs, the spans, the
uls, the lis, the tables, and so forth.
You need to transfer it from one state to another state,
because that essentially is going to drive
the rendering engine.
But the thing that's different between [? round-tree ?]
applications and single-page applications that you have to
deal a lot of it about the internal thing called RAM.
BRAD GREEN: Memory.
MISKO HEVERY: Memory.
Memory, I see.
BRAD GREEN: We call it memory these days.
MISKO HEVERY: So the heap of the program, right?
So instead of getting the data in line with your HTML to get
data separately, you load it into the memory.
And now the problem becomes once we get it to memory, how
do we get it to the DOM?
And then back when the user interacts into the memory, and
into the database?
And so our passion really became how do we simplify this
flow of data to the DOM, and back to the database.
And this is essentially what became Angular.
BRAD GREEN: Right.
And we got a logo.
But let's see how this works.
And we're going to go to an example of the basics of
moving back and forth.
And this is one of those three D's--
and we'll actually describe them-- not our goals.
But it's important.
So data-binding, the way this works.
We've got a--
just in a template, we're actually able to express kind
of an interesting case.
Well, let's actually see how this works before we
dive into the code.
So Misko's a text box here, and you'll notice how he
types, the words that he types appears below, and the word
"hi" appears when there's something in the box.
So if he deletes all the text in the box, the word "hi" goes
away, and we don't see anything.
So let's go back and take a look at how this works.
So at the top, you'll notice in the HTML tag, we have an
extra attribute that is not actually
part of the HTML spec.
And there-- all these things in green are--
these are extensions we've added.
And we call them directives.
But they allow us to assemble the application
in interesting ways.
And here on the input field, what we've said is that the
model for our data-- the place in memory where this lives--
we're going to name it with an object called "user," and we
have a property called "name." And that we want this thing
synced up, so that whenever somebody types that in memory,
it should update this user.name, and we
can use that elsewhere.
So right below it in the paragraph tag, we want to
place that text.
So what we do in double curlies-- we call this
interpolation--
we're able to place that text right in there just by putting
those double curlies in.
This is a familiar syntax that's used in other
templatinig languages.
But we're also able to use it not only to modify what data
is there, but to control whether it's shown or hidden.
So in the p tag, we have ng-show equals username.
Well, what this says is that showing and hiding should be
controlled by presence of text in there.
If there's no text, hide it.
If there's text, show it.
But we had an interesting eureka moment in here, which
is that our templating system was actually HTML, which means
you can use all your existing HTML editors, such as
Dreamweaver, or your HTML editor inside of your IDE.
And this is in stark contrast to most other templating
systems that happen to be templating languages of their
own, and just happen to produce HTML on the end.
This is actually HTML all the way through.
And that makes it easy for people to pick up and learn,
such as for web developers-- or, for web designers who are
already familiar with the HTML paradigm.
BRAD GREEN: That's right, but data-binding isn't the whole
story, right?
So we also want to put in but some other bits when we create
an application.
MISKO HEVERY: So at the beginning, I mentioned the
idea was, could I build a very simple web application without
having actually any kind of logic inside--
without having to write any logic, any program just by
using data-binding?
And if you wanted to build a real application, sooner or
later you come to the situation where, well, you
have to put the logic in there.
And so it's not sufficient to just have a good data-binding
story, but also have a good story about how do we manage
all the code that has to be written, and how does the code
interact with the data-binding, as well.
BRAD GREEN: That's right.
And let's take a look at another example.
So here we've got a slightly more complex example where
we've got two files-- one index.html on the left, end
UserController.js on the right.
And again, let's take a look at how this works before we
walk through the code.
So Misko's going to open his second tab, and we've got a
text input.
We've got the word "Larry" in there.
And when he clicks the word--
the bye button, it says, "bye Larry." Nothing too complex.
But if he changes the text and clicks bye, it updates to use
"Google I/O" as the text.
OK, let's take a look at how we do this.
So now, we've got--
we need some logic.
We need some way to take that text that somebody typed, and
move it somewhere where we can use in our bye button.
So our template on the left-hand side, we're adding
another piece to the template.
We are now telling Angular to construct a template that
relates to some code.
And in this case, we're specifying that a class called
UserController we're going to use to manage
this part of the DOM.
And this is some new syntax, so for people who have used
Angular before, this is some new syntactic sugar we'll be
releasing tomorrow.
But we're able to create an alias for UserController.
We're just going to call it UControl and then we can refer
to it later.
And what we'll see is that we can put attributes on UControl
that we want to access as part of our model.
So the input will bind to UControl.user.first.
And for clicking the button-- when users click it-- it will
specific an ng-click there that UControl should call the
bye function that we defined there on the right-hand side.
MISKO HEVERY: But I wanted to point out something over here,
which is that the UserController has no access
to the DOM.
There's also no special thing you have to inherit from, no
special way that you have to instantiate your model, other
than regular object.
And notice there is no API one has to call inside of Angular.
This is really just a plain old JavaScript type that
exists in JavaScript.
BRAD GREEN: Right.
And maybe even more importantly, notice that
there's no new-- we never call new on UserController.
We don't create it.
Just by specifying in the ng-controller tag, Angular
knows enough to create it at the right moment when this
view comes into my application.
It creates a controller, and attaches it-- or, it hands it
the right things in the DOM.
MISKO HEVERY: Right So when you have a model-view
controller, in Angular, everything is driven by the
view on the left-hand side over here.
And the view says I need the controller, and so the
instantiation of the controller has to happen,
which then goes ahead and instantiates the model.
Now the thing to notice over here is that all of the arrows
point away from the view, and into the
controller or the model.
And because the arrows point in this particular direction,
it means that one doesn't have to start with the view.
One can start with instantiating the controller
and the model separately.
And this is very wonderful in tests.
And also, this allows you to easily reskin your application
for different devices.
BRAD GREEN: Right.
And what this really means is that my view and my controller
and my model are decoupled, meaning I could change the
view with the same business logic and the same model for
maybe different devices, or different use cases.
So Misko, let's talk about how this assembly of the
application actually works then.
MISKO HEVERY: So here, we're taking a simple case, which we
just saw with the hello world, and making it a little more
complicated by saying instead of popping up a dialog box,
maybe we can use a voice synthesis to actually say the
words that we're about to display in the LR box.
So in this case, we again need to have a UserController, but
notice the UserController says it needs VoiceSynth.
And below, we have a definition of what Voicesynth
might look like, which then uses the web audio to actually
speak to-- to generate the text, and speak
it through the speakers.
And a thing to notice over here is that the view says it
needs a UserController.
And the dependency injection system that tries to
instantiate the controller, but it notices--
a-ha--
but in order to get the UserController going, I need
to have a VoiceSynth object.
So then it goes one level lower and says, OK, let me
make one of the voice synth.
But again, it sees, well, I need a web audio, so it goes
one level further yet, and it tries-- it
instantiates web audio.
Hopefully, that has no dependencies.
And then it takes the web audio instance, puts it inside
of the VoiceSynth instance, which then is placed inside of
the UserController instance.
And the whole controller is then handed over to the view.
BRAD GREEN: But let's talk a little bit about how this
actually works.
Like nowhere in my UserController do I actually
directly refer to VoiceSynth?
MISKO HEVERY: That's right.
So normally, when you have a constructor parameter, such as
over here, those don't matter.
I mean, they're only there for the user-- for the developer
to kind of understand what's going on.
But in our case, we actually look at the actual text, and
we use the VoiceSynth key to match it up against the
VoiceSynth class so that we can instantiate it.
BRAD GREEN: Right, very cool.
Now this is great for building my app, and
rearranging my app.
If I go to refactor my application, this is cool.
But it's also great in testing.
MISKO HEVERY: That's right.
So let's say we wanted to test this thing.
So first of all, we probably don't want to instantiate the
whole HTML5 DOM.
That's expensive.
So we'll start a layer lower, and we're going to say, well,
that's just instantiated UserController.
But tests don't hear.
They don't have ears.
BRAD GREEN: They hear very poorly.
MISKO HEVERY: Yes.
And so we would really like to do is replace the VoiceSynth--
the actual voice synthesizer--
with a VoiceSynthMock.
And so what we're really trying to tell to the
dependency injection system is that we're going to change the
recipe by which you build the application slightly so that
we can get a subset of the application going configured
in a slightly different way.
And once we get the subset, it's very easy to apply
stimulus to it, and assert that the right methods get
called on a VoiceSynth.
BRAD GREEN: Right.
OK, let's take minute and step back, and talk about what do
we got so far.
MISKO HEVERY: So we have this imperative world, and we have
this declarative world, imperative world being, let's
say I wanted to center something.
In imperative world, you have to compute the width of the
page, the width of the thing you want to center, divide it
by half to get the midpoint, align the midpoints, and then
render the text that you want.
The trouble with this way of doing it is when somebody else
comes afterwards and looks at the code, and they're going to
have to reverse-engineer.
What is the side effect of this piece of code?
Declarative is, on the other hand, if you simply say I want
to center to this thing, and it doesn't matter where the
implementation is.
And actually, the concept of centering might actually be
implemented slightly differently in different
browsers, as long as the end result is the same thing.
And so, up to now, usually when you have a framework, the
developers really are just, hand it over, and say, you get
to use this imperative thing-- this is you, you can play with
it any way you want.
But the declarative thing, well, we'll have the framework
give you some vocabulary for the declarative stuff, but
it's essentially fixed.
So we thought, wouldn't it be great if we could take this
vocabulary and extend it.
And this was our a-ha moment, and saying, hm, why are we in
some way special that we can create vocabulary, but the
developer can't?
What if we gave the same tools to the developer, as well?
And so we have a change in Angular in that the developer
gets to use the imperative or gets to use the declarative
world, depending on what they feel like is the best way to
solve this particular problem.
BRAD GREEN: That's right.
Let's take a look at some examples.
So we've seen how directives can be used to express the way
we wire our application together with ng-model and
ng-controller, and the way we change the structure of the
DOM with ng-show, as we saw.
But you can also use it to create reusable components.
For example, if I wanted maybe a star rating component, I
could, after implementing it, then just use it in my
template by saying, angle-bracket-rating, and then
pass the data to it that it needs through its attributes.
You can create more complex things where you've got
nested, or components that need to collaborate.
For example, a set of tabs will have the information
about which one is highlighted, and which one
should I paint with a box around it.
And then the individual tabs inside will contain the title
and the content.
You could also do it not just by element name, but also by
attribute name.
And so you can create things like a tool tip, where you
could place it on a span or on a tab or in a rating, or
anything else in the UI.
OK, we've covered kind of the basics in Angular.
And now let's take it back to the way we were kind of
creating apps before we wrote the Angular framework.
We weren't using jQuery, but we're going to use jQuery here
because we feel like a lot of folks know it.
We've got a simple application.
Misko's going to show us.
MISKO HEVERY: It says you're going to tap dance, but you
got no shoes.
BRAD GREEN: I took them off because I knew
that line was in there.
And then we're going to rewrite the application in
Angular, and show some of the differences.
MISKO HEVERY: So here's a very simple application.
All it really does is it shows you a list of projects.
And what you can do is you can add, and it brings you to the
detailed view.
Notice when I click the Add, it's a single-page
application, the URL didn't actually change.
It's the same URL.
I can say something over here, hit Save, and now I have my
new item inside of the list.
I can further click on it, and delete it.
BRAD GREEN: I should mention, there is a very simple RESTful
server running a node on the backend here that we used to
persist the project.
MISKO HEVERY: So really, it's just an
application with two views--
very simple.
And what's strange about this thing is that it takes me two
sentences to explain what it does, yet it takes me about
200 lines of both HTML and JavaScript to actually
implement this.
And so there's a little bit of a disconnect over there.
So what does this look like?
Well, so this is a list of projects.
And in this case, we have a template, which is a table.
And inside of the table head, we have this plus on the
right-hand side.
And notice what we have to do here.
We have to say, well, there's a link-- so that it looks like
a link-- but actually, it actually goes nowhere.
Inside of JavaScript later on, I'll show you, you basically
have to set up a click listener, and we have to
prevent the default behavior of the browser-- which is to
navigate to a link--
and actually just modify the DOM to
render the details page.
And this kind of breaks the paradigm of what a web
application is supposed to be.
And so we'll show you how Angular can make better usage
of this thing.
The other thing is that in the table row, the same kind of a
click has to happen, but there's no-- it isn't clear
what the text goes inside of here.
And so we actually have to get a hold of this thing from the
JavaScript side, as well.
We do something similar for the form for the details view.
So let's have a look at how is this implemented in
JavaScript.
So the first thing you're going to notice is that
there's a tremendous number of selectors that have to get
executed in order to get a hold of the right
pieces of the DOM.
And what the selectors essentially end up doing is
they are essentially creating the arrow going in the
opposite direction from the code to the view that creates
coupling, and it makes it difficult for a web designer
to come in and move things around, and number break the
CSS selectors that select them.
BRAD GREEN: Even if we're using IDs, it's still fragile.
It's still something that you have to be careful about when
you move things around.
MISKO HEVERY: That's right.
And so this basically shows you how we rendered the page
on the right-hand side.
So we had this show method--
what it does is, well, it has to assume that there might
have been a different page before, so it has to remove
the existing content.
It has to add its template to it.
It has to remove any existing projects that happened to be
inside of the template before.
And it has to set up this click listener, which I talked
to you-- mentioned briefly before, which does the
navigation for one page to another.
We then go and do an Ajax to the server.
And for each project, we basically do clone of the
table row, write the data into the right locations.
And again, we have to set up a click listener which
transitions us from the detail to the--
I'm sorry, from the list view to the detail view.
And so, what's lost in the process over here is it's not
clear what this thing actually does.
There's tons of DOM manipulation, and the actual
business logic of this particulate
page is lost in here.
BRAD GREEN: Right.
So let's fast forward, and let's
reimplement it in Angular.
Let's see how it's different.
MISKO HEVERY: So let's look at the template again.
What we have done is we have removed the templates from
index.html and replaced them with something called a view.
So this is essentially a hole into which individual pages
will be loaded.
And the actual pages get moved into a separate file.
BRAD GREEN: Now this template, the top of the template right
now-- if this was a more complex application, this is
where we would put maybe are top nav, or our left-hand nav.
But here it's simple.
We just have one view that we swap in and out.
MISKO HEVERY: Exactly.
Now notice, instead of registering a click listener
for this href, we let the href do what the web does best,
which is create links.
So this case, we're saying, look, there is a sub-view of
this particular page, which is the slash project with no ID.
And this is what's tied to the URL.
So now if I reload this application, and I click on
the plus, notice that the URL has changed.
Now a nice side effect of this is all of a sudden, our back
and forth button just work without really any effort
whatsoever.
BRAD GREEN: Now, we could have done that in the jQuery
reversion--
just a lot more work.
MISKO HEVERY: We could have done it, and it would
be a lot more work.
But this is a model that people are very familiar with,
that developers are familiar with, because it's the kind of
round-trip application model, except the round-trip, it all
happens in the browser.
There's no actual round-tripping.
This is still a single-page application that we have here.
So the next thing to notice is that, instead of manually
making clones on the table row, we have this other
directive called an ng-repeat, which basically says for each
project in the list of projects--
and I'll explain where the list of
projects comes in a second--
we just want to have a copy of the TR, and this does the
copying and cloning and managing it automatically.
The next thing is that all of the double curlies shown over
here naturally show us where things belong, so we don't
have to have selectors to place them there.
And finally, again, we have an example of deep-linking where,
if you want to click on an Edit button, it just means
that we want to update the URL with a specific ID in the URL
that becomes bookmarkable.
And again, all the magic of bookmarks happens
automatically for us.
So let's look at how this changes inside of the
JavaScript.
And this is the goal that we were more after, which was, if
you want to explain to somebody what this particular
page does, it's just as simple as saying, give
me a list of projects.
It's a single sentence.
And I want this to be a single statement inside
of my code, as well.
So in this case, we're saying we have a project list
controller that is a single item in there.
So how did we know to load this particular controller?
Well, if we look over here, this is
where we set up routes.
We're saying we're emulating kind of a round-trip
application, but in the browser.
So we have to say that when the URL--
which is shown right here--
is a regular slash, we activate the project list
controller and the project list template.
And so the project list controller simply says, go to
the database, and fetch me a project query.
BRAD GREEN: OK, so there's something
interesting going on here.
We should explain.
When we query, we're actually connecting to the database,
but you'll notice, there's no call-backs there.
What's really going on, Miska?
MISKO HEVERY: So this is a place where we get to take
advantage of data-binding in a very unique way.
So project.query query does essentially an XHR in the
background.
And the way it does this is that it returns immediately,
but it returns an empty set, because the server will
respond in some future point in time with
the actual data set.
And it takes that ng-array, and just
assigns it to the project.
So when the ng-repeat gets notified to say, hey, I have a
new data for you inside of the projects, it simply says, oh,
there's nothing there, and therefore it renders nothing.
But at some future point in time, the data actually does
show up, and updates the same instance of the array, which
then automatically causes the ng-repeat to unroll itself and
make as many copies of the project as you have.
So in the simple situation where all you need is to fetch
some data and render it, we can actually bypass the whole
need to have a call back.
Now the second thing is, where did the project come from?
This is where dependency injection comes in, and this
is how the application actually gets assembled, which
we kind of mentioned that earlier.
So right above here, it says a project can be made by using
something called a resource.
A resource is just a service in Angular that we can use to
build JavaScript types for the RESTful backend services.
So we're just saying, this is going to be a standard RESTful
object, which we can just use query on to
fetch the data set.
And again, notice that the application gets automatically
assembled for us.
So just simply by navigating to the right URL causes the
right route to be activated, which then activates the right
controller, which then knows to go and make a new project,
which then knows to build the project using the resource.
And the whole application gets assembled without us ever
having to do any of this stuff.
Similarly, inside of the project [? details ?]
controller, we can simply say, show me an existing project or
a new project, depending on whether we have an ID or not.
BRAD GREEN: So how many lines of code do we have?
MISKO HEVERY: So we are about 40 lines of code.
And we actually added a new behavior, because we have
deep-linking available for us.
BRAD GREEN: OK, that's very cool.
As your manager, however, I need to ask you to add more
features to this application.
MISKO HEVERY: More features?
OK
BRAD GREEN: Miska, could you please add more features?
MISKO HEVERY: What feature would you like to add?
BRAD GREEN: OK, well, thanks.
So this is a list of projects--
probably frameworks.
People like to write frameworks, as we know.
It could get long.
How about add the ability to filter how many frameworks are
there if I want to search for the one I want.
MISKO HEVERY: So the first thing you need to add is an
input box, right?
So if I refresh now, I have an input box.
And if I type into it, this text actually ends up in the
memory location called search text.
Now we need to do something with this particular case.
Now one of things we have-- and I'm sure you're familiar
with in UNIX-- is the concept of filters, which we have, as
well as using a simple pipe-character.
And we can run it through kind of a special [? mini-ask ?]
functions.
In this case, there's a function called filter--
I know the naming is a bit confusing.
BRAD GREEN: I see, yeah.
MISKO HEVERY: But what a filter does it just looks
through the list of objects in an array, and sees if any of
the objects happen to have a text inside of it that matches
the search text criteria inside of the input box.
So now if I refresh this, you will see that as I type the
word "web," it will show only those projects that actually
have the word "web" inside of them.
Notice how the repeater automatically grows and
shrinks as the filtering changes.
BRAD GREEN: OK, very cool.
However, modern applications use animation to show me-- to
give me a more intuitive sense of what's going.
Could you maybe animate the items in the
list in and out as--
MISKO HEVERY: Do you understand how complicated
animations are?
BRAD GREEN: I don't.
I'm a manager.
MISKO HEVERY: I see.
[APPLAUSE]
So animations--
as you guys all know, I'm sure-- are complex things,
because you have to add things to the DOM before they
actually come on to stage, then you have to transition
them to keep track of timers, remove things, and so on.
And this is where the power of the declarative world really
comes from.
Because really, what I want to express to when I'm building
the application is there is something called animation.
And I want to animate this thing using a slide animation.
A slide animation is just something I've declared inside
of my CSS, as this is the set of transitions we want to
apply to the system.
But actually managing the DOM's add and removing,
setting the classes at the right time is actually managed
by this ng-animate directive.
So let's refresh this.
And notice, as I type "web" now, it removes and adds item
in the correct way with just a couple of keystrokes.
[APPLAUSE]
BRAD GREEN: Sassy.
Very sassy.
All right, so we're kind of at the end of our coding portion.
Miska has, however, added some other interesting features
also in sort of a declarative way.
But we'll just demo them.
You can go to the GitHub repository.
We'll give you a link at the end of the session.
But you can also do things like animate between views.
So if I was on a mobile device, I would want to be
able to slide back and forth.
We've also done form validation, so you can have
things that are required, or that are not really required
but they have to be in a specific reg-x format, like
something must be a URL.
And these things, as I mentioned, we can add in also
a purely declarative way.
These are well-understood problems.
We can just put them in the template.
So we should talk about a couple of other things before
we wrap up.
One of the things that people tell us is
fantastic about Angular--
besides the framework--
is the community.
And there thousands--
hundreds of thousands of folks in the community who do a
great job of helping each other, documenting new things
in Angular, adding code, all kinds of things.
There are meet-ups that happen regularly.
There are-- on our Google group, on Twitter, on Stack
Overflow, and Google+.
There's a tremendous community.
There's an IRC channel that's very active, too.
As you can see from the map, there are actually still some
places in the world where we would love to see monthly
meet-ups, and we'd love to help you make these happen.
Let's go next.
So the rest of the ecosystem, Angular kind of fits a small
piece of the whole web development puzzle.
And I think this is kind of cool, because it's made space
for other people to create things that fit in the world.
We've developed some of them, but a lot of other folks have
created things, too.
So in the world of tools, one of the things we created is a
Chrome Developer Tools plug-in called Batarang.
And Batarang lets you visualize your application,
visualize your data-bindings, where your template is set up,
optimize the performance, and debug it--
for all of the Angular-specific concepts.
The good folks over WebStorm have created a plug-in that
makes it Angular-syntax aware.
And a lot of us use WebStorm on the team because of it.
We've been working with Addy Osmani and Paul Irish and the
other folks on Yeoman to make it very easy to scaffold an
Angular application, to update its dependencies, and then to
build and deploy it when you're ready.
And then, one of our team members, Vojta, has done
something I think is extra special.
We talk a lot about testing.
But making the framework testable was
not the full story.
He wrote a test-runner called Karma.
And Karma, we think, is the fastest, most reliable,
easiest test-runner on the planet.
Matter of fact, I would say it would change your life.
We should do a demo of that later.
But it's awesome.
Go download it.
Search for karma test-runner.
It's awesome.
Now when we were talking about directives, we said that you
can write your own things, like star ratings and
tabs and tool tips.
And it turns out a lot you don't want to be doing that.
And so, there are a ton of directives--
web components--
that you can just use.
And we have things like the Angular UI Project.
It's not part of Angular but, they've collected a number of
the web components from across the web.
And they're specifically a Twitter Bootstrap theme set of
components.
There are also commercial versions, like KendoUI and
Wijmo So you can come out of the box with a whole bunch of
components that you just snap together like
LEGOs in your template.
In the rest of the world of libraries, there are things
like BreezeJS that gives you a very rich set of tools for
manipulating data that comes from SQL and NoSQL databases.
If you want a database in the cloud, there's Firebase, who
have created Angular-specific binding so that you can use
them with our data-binding system.
And the folks at Salesforce recently created a developer
tools pack that lets you create Angular applications
with Salesforce on the backend on mobile devices.
And then there's books.
I actually--
I wrote one of them, the one with the fish.
I think that is the most handsome of the books.
But there--
I think last count, there are seven books.
Really, you should buy them all.
I could not choose.
All right, so thank you everybody.
Thanks so much.
We--
at the lower right-hand side is the link for our GitHub
repository, for the demos that you saw today.
Misko and I are available on Twitter and Google+ if you
want to reach out to us.
We're going to be in the Chrome Sandbox upstairs for
the next half hour.
We've got a little bit of time for questions.
But we'll be there.
We'd love to answer questions.
We've got some stickers to hand out upstairs.
And then Angular books are going to be in that Chrome
Sandbox area on Thursday and Friday all day long.
Thank you for coming.
Really appreciate it.
[APPLAUSE]
So, let's go over here on the mic.
AUDIENCE: So good to see Angular at I/O.
BRAD GREEN: Thank you.
AUDIENCE: So my question is, how do you configure the curly
braces for data-binding?
That is configurable, right?
I'm using Jekyll with Liquid templates, and there are curly
braces used there as well.
So I'd like to be able to configure that.
And do you recommend against it?
MISKO HEVERY: Yes, so there is a interpolation provider which
allows you to configure the starting and ending set of
sequence of characters that will do this.
And so you could use that.
The caveat is that, if you're using a third-party library or
third-party widget library that assumes curly braces, you
might break them.
It's not true?
[INAUDIBLE]
Oh, we compensate.
Oh, we fixed it now.
BRAD GREEN: OK, good.
MISKO HEVERY: You can change it using the--
BRAD GREEN: It just works.
It just works.
Thank you, Igor.
AUDIENCE: Great, thanks.
BRAD GREEN: All right, sure.
AUDIENCE: I come from China as a [INAUDIBLE]
[? TGD ?]
organizer.
So I notice that a map, a pocket of all
the Angular's community.
But in fact, AngularJS [? dot-send ?]
is building just users [INAUDIBLE].
In fact, in China, it is very--
so many people like AngularJS.
so my question is how make the AngularJS community, and you
can address--
you can know it.
I just want to--
I think you [? might ?].
You're not quite [? sure? ?]
BRAD GREEN: I'm kind of missing the question.
AUDIENCE: I'm trying to say [INAUDIBLE]
[INTERPOSING VOICES]
MISKO HEVERY: I think he's saying there's an awesome
[INAUDIBLE]
AUDIENCE: [INAUDIBLE]
BRAD GREEN: You're saying in China, there's a fantastic
JavaScript community, and there's AngularJS going on.
AUDIENCE: But we lost it in your map.
So I have a question, why--
BRAD GREEN: Ah.
Tell me where it should go, and I'll put it on my map.
AUDIENCE: OK, thank you.
BRAD GREEN: Yeah, that would be awesome.
Thank you, thank you.
AUDIENCE: How is Google using AngularJS internally?
Are there going to be apps that we use?
Or that consumers use?
BRAD GREEN: Yeah.
We've built a lot of internal apps on Angular.
Google Feedback was one of them.
The two big external applications that we've built
on top of it is DoubleClick, which makes
some money for Google.
This is display advertising.
I mean a lot, actually.
And then YouTube has built their--
it's kind of like an embedded in the PlayStation 3
application.
So the live player that you get with PlayStation 3, that's
built in Angular.
There's some more stuff on the way.
Can't pre-announce it.
AUDIENCE: Yeah, because that's always a concern that you guys
keep using it so that it keeps growing, right?
BRAD GREEN: Indeed, indeed.
It's well-loved within Google.
AUDIENCE: OK.
BRAD GREEN: Thank you.
And over here.
AUDIENCE: First question is, the query--
it does have a call back, though, right, if I need it?
BRAD GREEN: That's right.
You can have a call back if you want to.
AUDIENCE: OK.
BRAD GREEN: Yeah, for catching errors, and there's some other
reasons you might want [INAUDIBLE].
AUDIENCE: And secondly, we think Google-- is there any
sort of internal fight with Backbone?
BRAD GREEN: There's actually no fight with Backbone in
terms of Google.
No.
There's none.
None whatsoever.
AUDIENCE: Thank you.
BRAD GREEN: Yeah.
Yes?
AUDIENCE: Hi, yes.
I just started using Angular for the first time actually a
couple of weeks ago.
BRAD GREEN: Thank you.
Awesome.
AUDIENCE: And I absolutely freaking love it.
MISKO HEVERY: Thank you.
AUDIENCE: So--
BRAD GREEN: Next question.
Awesome.
No, go.
AUDIENCE: The search
functionality, it's really nice.
But can you talk a little bit about patterns to use when the
data set is big, and it needs to be paged in
and out, and how--
what's the right way of setting up your services?
MISKO HEVERY: I think that's way beyond what we
can answer on stage.
BRAD GREEN: Yeah.
I mean, I can point you-- there are several services
that help doing this, for help doing the pagination, and
doing sort of an infinite scroll effect, which is what
folks often want.
AUDIENCE: The search, the actual search, right?
The ng-search stuff.
Not just the scrolling, but the actual--
BRAD GREEN: Yeah.
So that as you type.
You want it like the Google homepage search style thing.
AUDIENCE: Yeah, even if I set up like a
backend search stuff.
BRAD GREEN: As Misko said, there are some details--
maybe come up to the Chrome Sandbox, and let's have
a chat about it.
MISKO HEVERY: Yes.
That's a better way of-- yes.
AUDIENCE: Thank you.
BRAD GREEN: Yeah Over here?
AUDIENCE: OK, first of all, thank you for making Angular.
You saved my bacon like two months ago making a site.
It's really awesome.
Two questions.
First, what are your recommendations towards search
engine optimization for sites built with Angular?
And the other one is, I'm currently trying to get a site
done in Angular, but the manager is concerned about
users who don't have JavaScript enabled, or what--
MISKO HEVERY: What year is this again?
BRAD GREEN: I think it's 2002.
But no-- so I can't help your manager, because he is living
somewhere else.
But as far as--
what was the first question?
AUDIENCE: SEO.
BRAD GREEN: SEO, yeah.
So there's a recipe for SEO.
There's a website called "Year Of Moo." It's
this guy named Mateo.
He worked with us on the animation directive actually.
And he is a very good documented
path for doing this.
Search for "Year of Moo" angular SEO.
MISKO HEVERY: And it has to do with the headless--
BRAD GREEN: Using PhantomJS to kind of render your pages.
AUDIENCE: OK.
And that wouldn't be penalized by you guys, as Google?
Because--
BRAD GREEN: No.
AUDIENCE: Since users are--
BRAD GREEN: There's no way for Google to know.
We see what you finally render.
AUDIENCE: Oh, OK Thank you.
BRAD GREEN: Sure.
Yeah?
AUDIENCE: So we already built a map with Backbone and other
stuff, and we don't have a-- it's like a financial app.
So now, do you think I could introduce Angular and, with
it's help-- because it's a huge app, a trading app, but
lot of Backbone, and a lot of stuff in it.
BRAD GREEN: So what is the core of the question?
Could you rewrite in Angular?
AUDIENCE: I mean, do I have to only rewrite something?
Or will it-- can I use this as a part of it?
Or how will this help--
MISKO HEVERY: Yeah.
I think [INAUDIBLE]
is [INAUDIBLE] do a full rewrite, or
you can do it partially.
And one of the things we wanted to make sure that
Angular plays nicely with other frameworks so that you
could rewrite an app one page at a time, or
something like that.
So there's even--
I've seen some blog posts about people trying to get
Angular to run together with Backbone.
So they'll use Backbone for the models, and Angular for
the data-binding and rendering.
So that should be possible.
AUDIENCE: Yeah, because we use data-binding of the Backbones.
Thanks.
MISKO HEVERY: I think we can make time for one more
question, and then time is running out.
BRAD GREEN: Yes.
Right over here?
And we'll hit the rest of you up in the sandbox.
AUDIENCE: All right, score for me.
So I actually have been using it for the past half
year, and loving it.
I have two very specific questions about ng-switch.
So one of them is, lately I've been doing a lot of nested
ng-switches.
One inside--
like for instance, one is true, and inside that another
ng-switch, and sometimes a third.
Should I be concerned about doing nested ng-switch?
That's question number one.
MISKO HEVERY: If you're just going to nest just a few
ng-switches, it shouldn't be an issue.
If you're gonna nest 50 of them, then maybe you should
look at a different way of doing it.
AUDIENCE: Yeah, OK.
That's good to know.
So the second one is, is there a good way to do undefine with
ng-switch, because I haven't been able to do that very
successfully.
So what I always have been doing is to actually have the
wrapper do a return true or false.
And then have it go to web [? branch ?] when true, and
then when false--
versus when I tried to do one undefined, it just doesn't
seem to fall to the right branch.
So not sure if anybody else has seen this similar problem.
BRAD GREEN: I didn't quite get it.
But maybe let's continue this back upstairs.
AUDIENCE: Yeah, OK.
Cool.
BRAD GREEN: Thank you everybody.
MISKO HEVERY: Thank you
BRAD GREEN: Thanks so much for coming