Placeholder Image

Subtitles section Play video

  • BRAD GREEN: OK.

  • Welcome everybody.

  • Thanks for coming to the first Angular conference or Angular

  • Meetup here in Mountain View in 2014.

  • So we've got I think a really good start of the year tonight.

  • I've got a couple of announcements,

  • like I always do.

  • Then Victor's going to come up and talk about Angular D3,

  • and Igor will finish up with how will

  • pull requests work in the Angular world.

  • A couple of announcements before we get going.

  • Like always, if you plan to talk, meaning ask a question,

  • and we hope you do, you will need to sign one of the forms

  • that Igor has right back there.

  • And I think we give you a T-shirt if you do such a thing.

  • Is that still true?

  • Yeah.

  • OK.

  • I think that's still true.

  • No pandering questions, just real questions.

  • And I think that's it.

  • With that, we'll get started.

  • So, not a lot of things happened in the world of Angular

  • in 2014, except we got a lot of releases out somehow.

  • Apparently, we don't observe holidays.

  • I think we've never gotten so many releases out

  • as we did between last Meetup and this one.

  • There's a couple of highlights in these four releases.

  • There was 114 pull requests closed.

  • A couple features got in, like we

  • have multi-line NG options now.

  • There's one jqLite feature for element dot one.

  • A ton of performance things went in for injector, resource,

  • compile, parse, broadcast, even in jqLite,

  • some things got faster.

  • And then a ton of bug fixes.

  • A lot of things around IE8, a whole bunch

  • of stuff in the animation bits, and across the rest of Angular.

  • In the world of Angular Dart, we got out two releases.

  • If you haven't been following along,

  • Angular Dart are the ports to the Dart language.

  • And it's kind of just getting started.

  • We're working towards the 1.0 release.

  • Some of the things that we added are getting parity

  • with Angular JS side.

  • So we're still adding a bunch of directives.

  • There's new things that got added there.

  • A lot of performance improvements to make it

  • perform very well on Dart.

  • This is still a bit of a new place for us.

  • And then we have some experimental supports

  • for this thing called shallow-repeat.

  • One other announcement I'd like to make

  • is that we have a conference going on in two days.

  • On the 16th we start in Salt Lake City.

  • Anybody coming there with us?

  • A couple-- Just us.

  • OK.

  • Yes, one over here.

  • Good.

  • Great.

  • So this is for everybody who's not coming.

  • We're actually going to be live streaming

  • the entire conference.

  • You can tune into it live and you can watch me again,

  • and some of the other folks, talk

  • about other interesting things in the world of Angular.

  • So please tune in.

  • I think it starts at 9:00 in the morning,

  • but that's maybe an hour off in Salt Lake time.

  • And I'll see you guys there.

  • One other announcement.

  • If you are interested in Angular on Dart,

  • the Dart team, along with us, we're

  • running this thing called Flight School to get you up

  • and running.

  • So if you want to learn the Dart language

  • and learn about Angular Dart on top of it.

  • This is happening in many cities around the world, and really

  • around the world.

  • If you just search for-- Sorry I don't have a link for it.

  • If you just search for Dart Flight School,

  • you'll find it as the first result.

  • And from Shanghai to Chicago you can find a local place

  • where you can come tune in and learn Angular Dart.

  • That's it for this month's announcements.

  • We'll have Victor come up and talk to us about D3.

  • VICTOR POWELL: Thanks Brad.

  • Can you hear me?

  • You're not supposed to see that.

  • So I'm a freelance data visualization engineer,

  • and I'm giving a talk, if you couldn't

  • tell by the slides, a talk on visualizing data

  • with Angular and D3.

  • Also, all the slides are going to be online after the talk,

  • so we'll pack out the link on the Meetup,

  • so you shouldn't have to worry about taking notes furiously.

  • We're going to be going over a lot.

  • This is sort of the combination of D3 and Angular.

  • So don't worry about that.

  • But before I begin, could I just get a quick show of hands.

  • Who's in some way at all familiar with Angular?

  • And don't be shy if you're not.

  • It's totally fine, because this is the cross-pollination

  • of Meetups from the E3 [INAUDIBLE] area.

  • OK, keep your hands up, though.

  • Keep your hands up.

  • Now, anyone that doesn't have their hand up,

  • look at the person that does have their hand up and talk

  • to them.

  • But it's a good turnout.

  • Nice hand raising for a D-- Not surprising

  • for an Angular Meetup.

  • Now anyone that has some familiarity with D3

  • go ahead and raise your hand.

  • Cool.

  • Now, if you're not familiar with D3, that's fine.

  • Find someone who is and talk to them, shake their hand,

  • say hello.

  • OK, now we're going to get into the talk.

  • So little about me, because I think it's important for you

  • to know a little bit about who I am so you'll pay attention.

  • You'll know why to listen in the first place.

  • I visualize data, obviously.

  • As a freelance developer, I've most recently

  • worked with a company called Monsoon

  • to help them build a dashboard for Hewlett Packard that

  • helps them analyze their data center energy

  • consumption across all of their data centers.

  • I teach at a hacker school in San Francisco

  • called Hack Reactor.

  • We actually have a few students here today-- former students,

  • not current students.

  • Some of those, actually.

  • OK.

  • So I also really like to explain things.

  • This is a visualization of the central limit

  • theorem I did a while back.

  • Here's also an explanation of the Monte Hall problem.

  • If you're not familiar, you should Google it and find

  • this explanation, and it'll tell you what it is

  • and why it's interesting.

  • Also, the Simpson's paradox, which

  • is a really interesting statistical anomaly--

  • I'm not going to get too much into details because it'll

  • probably just confuse you, but if you read this,

  • hopefully you won't be confused anymore.

  • I'm sorry.

  • A lot of these data visualizations

  • I've also done with my good friend Lewis-- he's here today.

  • Lewis Lehe, or Le-- you don't pronounce the H-E.

  • I'm also writing a book with Ari Lerner, who

  • is in charge of ng-newsletter, or puts together ng-newsletter.

  • And he's also written the book, the ng-book.

  • This book is still in a peer release state,

  • so it's not done completely, but if you buy it now

  • you'll get a discount over the release price.

  • And if you need help understanding your data,

  • send me an email and maybe I can help,

  • or the duo combination of me and Lewis.

  • So no more ads.

  • Let's start to get into the good parts.

  • So just to give you a high level view,

  • this talk's going to be on why and how you should use Angular

  • and D3 for doing data visualizations.

  • Before we do that, though, let's talk a little

  • about why you should care about data

  • visualization in the first place.

  • And to do that, I'd like to show you

  • one of my most favorite examples, Anscombe's quartet.

  • This is a series of four data sets with x and y values

  • for each.

  • As a table it's kind of hard to understand, so maybe

  • as a good idea, let's look at the summary statistics

  • of that data set.

  • But when we do that, unfortunately, they all

  • happen to have exactly the same summary statistics.

  • How is that possible?

  • That's so frustrating.

  • The mean of x and variance of x, the mean of y,

  • the variance of y, correlation of x and y,

  • and the linear regression is exactly the same.

  • And if we just look at the summary statistics,

  • that's very confusing, because all the data

  • seem somewhat different.

  • But it becomes immediately apparent

  • when we visualize the data, and we can see clearly

  • that the data sets represent completely different behavior.

  • So, OK, we understand why data visualization is important,

  • but why use Angular for doing data visualization?

  • Chief among them all are directives.

  • For those not familiar with directives,

  • give us essentially custom HTML tags.

  • It also allows our visualizations

  • to stay modular and self-contained

  • so that we can pick them up and drop them

  • in to some other application fairly easily.

  • But there's more reasons than just directives

  • for doing data visualization.

  • Some of those we'll get into, but for the most part

  • it's directives.

  • I like to think of directives as input fields.

  • They're kind of like directives that the browser gives us

  • automatically.

  • They're not actual directives in an Angular sense.

  • But they are like directives in that they encapsulate

  • a lot of behavior and we're given a simple API

  • to plug into them.

  • So the one example right here is the range input.

  • And I specify the min and the maximum value,

  • and then the current value.

  • And then it, the browser, handles

  • creating the slider, and the knob,

  • and watching for changes to that knob,

  • and updating the value for me.

  • I don't have to worry about the internals of that slider.

  • It's just an input range.

  • Same thing for the date input field.

  • There's really a lot of complex user interaction

  • here that the browser gives us for free,

  • but it abstracts away all those concerns for us.

  • Well, wouldn't it be nice if we could have something

  • like a donut chart element, and then we

  • wouldn't have to worry about the internals.

  • We could just plug our data into it,

  • and not have to, after having created our element,

  • not have to worry about how it does all that it does.

  • Well, directives make this possible.

  • Beyond directives, some of the other interesting features

  • that Angular gives us when we have our visualizations

  • and directives are things like ng-switch

  • for conditional templating.

  • So let's say, for example, based on some criteria,

  • we would like a pie chart to be displayed with our data,

  • but maybe in some other condition

  • we'd like a bar chart to be there instead.

  • Another really great feature of Angular that blends well, that

  • makes data visualization a lot easier is ng-repeat.

  • Small multiples is this idea, a powerful data visualization

  • tool, originally popularized by Edward Tufte,

  • and it facilitates the comparisons

  • of change across multiple charts side by side.

  • So this is a classic example of-- I'm

  • sorry-- of small multiples by Eadweard Muybridge,

  • and it's called a Horse in Motion.

  • You might be wondering, though, why can't we

  • just use animation?

  • Why can't we just play a video of a horse running?

  • Wouldn't that convey all the information?

  • Well, it turns out-- I'm sorry, here's

  • a little graphic I forgot to show.

  • Why can't we just have this?

  • Well, there's a few limitations to this video.

  • For one, we're stuck in the frame

  • of the playback of the video.

  • But say, as was the case in this original example,

  • the horse is running so fast that we actually

  • can't see whether or not it's lifting its legs up,

  • or if all of its legs are in the air

  • at the same time, which was the original bet between the two

  • people that generated this visualization

  • in the first place.

  • But another drawback is that we're

  • stuck to only getting an additional dimension,

  • but with small multiples we can go over columns and rows

  • to get an extra two dimensions of data.

  • So take this example from Andrew Gelman,

  • which would be impossible with simple animation.

  • It shows support for school vouchers

  • by race, income, and state.

  • And we can really see some really interesting insights,

  • if you look down towards the bottom.

  • People with low income-- Sorry.

  • Let me backtrack a little bit.

  • Not surprisingly, rich, white people

  • really like school vouchers.

  • But surprisingly, so do poor blacks and Hispanics.

  • Whereas, white evangelicals and white non-religions

  • of low to medium economic status are the ones who oppose it.

  • So the map itself only has two dimensions of information,

  • but the whole visualization achieves

  • four levels of dimensions, it's four dimensions of data,

  • by repeating the graphic along the rows and columns.

  • So this is actually really easy with Angular,

  • just by using the ng-repeat.

  • So this is a simple example of a chart,

  • of iterating over several charts,

  • and then creating the donut chart directive

  • for all the charts that we have on our scope.

  • We can even put ng-repeats inside of ng-repeats.

  • Yo dog.

  • Because no one ever made that joke at a program unit before.

  • So I have a little demo of that.

  • Hopefully it'll load.

  • It did not in your window, it loaded in mine.

  • So here's the visualization.

  • It's life expectancy by sex, race, and state.

  • And I'm just using the same Mac directive

  • for all of those elements.

  • Let me see if I can show you the Dom for this.

  • The window is very tight.

  • So this ends up being what the actual Dom looks

  • like after Angular has gone and done its dirty work.

  • And for every one of these ng-repeats

  • there's an inner ng-repeat that iterates

  • through all of the different columns.

  • This example is also in the slide,

  • so if you're interested in seeing more about how,

  • in fact, this visualization was generated,

  • just pull the slides after the talk.

  • Also with Angular, it makes it pretty easy

  • to do responsive design, which is useful just

  • for web development in general.

  • But is very handy, specifically for data visualizations.

  • I'll reload this demo.

  • And you can see that as I resize the window,

  • the graph inside of it is changing dynamically

  • in response to the changes in the window.

  • Again, that demo is available in the slides repository.

  • Another really great thing about Angular

  • is it makes it easy to do interactivity, basically

  • to hook up different visualizations

  • so that they represent or are connected in some way.

  • And so here is the previous example

  • I showed you earlier that me and Lewis built

  • to explain the Simpson's paradox.

  • And see, when we drag the sliders, the table of bar

  • charts and donut charts updates accordingly.

  • And without Angular, this would be rather tedious.

  • There's also another more involved example

  • of interactivity across visualizations.

  • This is the demo application you would

  • need if you were creating a video game

  • and you wanted to have non-playable characters.

  • You could then add or remove certain attributes,

  • in our case, web strength, speed, and agility

  • for each of the different characters.

  • So here I'll add a non-playable character,

  • and that shows up down at the bottom.

  • But so does its average appear at the top.

  • And I can add multiple different characters,

  • and it will affect the average.

  • So if I click on one of the attributes,

  • you'll see the averages above, updating accordingly.

  • Or I could change the min and max

  • of the different attributes.

  • Or I could add additional attributes.

  • And again, because Angular makes responsive design a lot easier,

  • and rescale this window, and the radar charts

  • will update accordingly.

  • So I just have one radar chart directive

  • that I'm using across all the different characters,

  • and also in the averages.

  • So I hope I've sufficiently convinced you

  • to use directives when doing data visualization.

  • And so, the next part of this talk

  • will actually be us going through and taking an existing

  • donut chart in D3 and converting it to an Angular directive.

  • Before I do that, just for those in the room that may not

  • be as familiar with D3, I'm just going

  • to go through 1,000 foot view of what D3 is

  • and why you would want to use it, pretty quickly.

  • But just to get you motivated for learning more about it.

  • Essentially, D3 is a way for you to manipulate the Dom based

  • on data.

  • That's where it gets its name, Data Driven Documents.

  • So if we wanted to, say, add or remove

  • different Dom elements that corresponded to pie chart

  • heights, it would be very easy to do that in D3.

  • D3's also very similar to jQuery in its syntax and the way

  • it works, but it adds a lot of functionality

  • that you would specifically need for doing data visualization.

  • I also like to think of D3 of just

  • being a collection of helper functions

  • that make it easier to do data visualization.

  • It's almost sort of like a meta library

  • that you can use to create your own visualizations.

  • It's not something you would use as just a way

  • to include a bar chart or pie chart.

  • It's really more for people wanting

  • to create their own visualizations,

  • not from some cookie cutter template.

  • So just to give you an example of some of flexibility

  • and power of D3, here's a really contrived example

  • of just some data, the values 20, 50 and 80.

  • I then select the body, kind of like in jQuery.

  • I also select divs that don't exist yet.

  • This is kind of the magic of D3.

  • And then I pen divs for every one of the elements in the data

  • and then set its width attribute to the value in the data.

  • And this is what a Dom ends up looking like.

  • There's three Dom elements, each of them

  • have widths, 20%, 50% and 80%.

  • So here's just a quick demo of that code, and the three

  • different div bar charts.

  • Another great thing about D3 is its collection

  • of these sort of helper functions,

  • and one in particular that I'll just skim over briefly

  • because we'll be using it later, is the D3 layout pie generator.

  • And so with it we can take data, create a generator, a pie

  • generator, and then path our data to that pie generator,

  • and it will give us all of the start and end angles

  • that would create a donut chart.

  • This is the code that would actually go and take

  • that data, that pie chart data, and create the necessary SVG

  • paths.

  • And SVG is just another-- It's just like the Dom.

  • I'm not going to get into for now,

  • but just think about it like any other Dom

  • components you'd like to manipulate.

  • And we'll set some styles and I'll pull out the demo.

  • And there it is.

  • It's in the upper right-hand corner, so that's no good.

  • So we'll have to translate it by some amount, so it's

  • in the center, or so it just is not

  • in the upper right-hand corner anymore.

  • And there it is, and there's our donut chart.

  • So we'll be using that code later on

  • to create our directive.

  • But just to give you some quick links,

  • so if you want to pull it down, these slides later,

  • and just learn more about how these work.

  • There's an SVG primer, A Good SVG Primer, by Scott Murray.

  • Let's Make a Bar Chart, by Mike Bostock.

  • And Thinking with Joins, also by Mike Bostock.

  • And I'll explain some of the magic

  • that I went through earlier.

  • So now we're really going to get into creating a directive.

  • So I'm actually going to hop out of this mirrored mode.

  • And so you'll be seeing what I see.

  • So there's a donut chart, very similar like what

  • we had before, except now we're giving it some color.

  • We're also dynamically changing its size,

  • depending on its container.

  • In this case, it's just a div, but it's not responsive yet.

  • So we'd like it to be in a directive.

  • So how do we about doing that?

  • Well, the first step, obviously, is we need to include Angular.

  • After that, we'll also need to create our app.

  • Give it a name.

  • And it won't have any dependencies.

  • We also need to tell Angular where our app begins,

  • and also create our directive.

  • And so we want it to be called donut chart, or donut.chart,

  • but we have to specify donut, capital C, Chart.

  • And the directive also needs to return

  • an object that has on it a link function.

  • And this link function you can think of as an constructor.

  • It will be called for every time you press the stamp down

  • to create new donut chart.

  • And that gets called with few arguments--

  • scope, the elements, type it out,

  • but really we're just going to call it EL for now.

  • And attr, we won't worry about that for now, either.

  • So I just want to test and make sure

  • that everything's wired up correctly.

  • Just do that.

  • I'm going to add an SVG to the element

  • inside of the directives, sort of the containing element.

  • This'll be called donut chart.

  • Element we access just like in jQuery,

  • since it's sort of a jQuery wrapped object.

  • It's not exactly jQuery, but it's

  • like a jQuery wrapped object.

  • So we'll need some way to reference

  • that element directly.

  • And then use D3 to select it, and then

  • a penned and SVG to it.

  • Oop.

  • But we should comment out our D3 code first.

  • Ah, but there's nothing there.

  • That's because we don't actually have a donut chart element.

  • Oh, but that doesn't work either.

  • We actually need to specify to Angular

  • that we'd like our directive to look like this.

  • But this will be the type of directive that we'll be using.

  • It will be donut-chart.

  • Obviously, there was nothing there before,

  • because we're just adding SVG.

  • But now the SVG is inside of our donut chart element.

  • I hope you all can see this.

  • So great.

  • Now we have everything we need to be able to just plug

  • in our D3 code right inside of our directive to have

  • what we had before.

  • But instead of selecting the div directly on the Dom,

  • we'll just pass the element to D3.

  • Actually, we don't even need to do that.

  • We'll just do EL equals EL0.

  • But our width and height is zero,

  • so why is that-- Oh, it's because we have absolute-- Oh,

  • because we're not actually selecting our donut

  • chart within our CSS.

  • We're selecting a CSS class called donut chart.

  • We're not actually selecting an element called donut chart.

  • So we'll need to change the CSS.

  • And there's our donut chart, inside of our directive.

  • So already, we can now reuse that donut chart.

  • So instead of giving it a width and height of 100% by 100%,

  • I'll just give it 100 for now, and tell

  • it to display like a block in block style.

  • And then we'll add another donut chart.

  • Great.

  • So now we have two donut charts inside of Angular.

  • But there's a problem.

  • We have our data inside of our directive,

  • and that's just not good.

  • Because every time we create a donut chart,

  • we don't want to always have that same data.

  • We like to be able to configure our donut

  • charts so it can have different data.

  • Something like this would be really nice.

  • The better example, maybe 10 and 3.

  • It's hard to come up with random numbers on the spot.

  • So that's actually a really easy change.

  • We could just use scope.data to reference the data scoped

  • variable on the donut chart.

  • But there's one small little change

  • we have to make to the object that we returned

  • from our directive, and that is we

  • have tell Angular that our directive will be receiving

  • a property on its scope called data.

  • Oops, that's not right.

  • So there you have it.

  • We'll make it a little bit bigger.

  • Whoa.

  • Maybe too big.

  • So great.

  • Now what would be really cool, though,

  • if our donut chart was responsive so

  • that we could resize the window, or we

  • wouldn't have to always resize the window for the donut chart

  • to fill the space.

  • So let's actually change the CSS back to be 100% by 100%.

  • Actually, I'm going to backtrack just a little bit.

  • Instead of doing that, let's actually

  • talk a little bit about ng-repeat,

  • which is what I was talking about earlier,

  • and it makes small multiples really easy.

  • So let's throw an ng-repeat inside of here

  • and see if that works.

  • Also, set charts on the outer scope

  • to be something like some array of data

  • within another array of data.

  • So now we have this array of arrays called charts,

  • and we'll iterate through it instead of ng-repeat

  • for all the different donut charts.

  • And we'll pass chart to the data property of our donut chart

  • directive.

  • Sweet.

  • So we have these two charts.

  • Also, I just want to talk a little bit

  • about using controller.

  • Generally, you don't want to actually

  • be putting all your data right in the Dom,

  • although it does really make it easy to quickly create

  • data visualization.

  • We'll, right now, go through the process

  • of creating a controller.

  • We'll call it donut chart controller.

  • I think that's long enough of a name.

  • Also have it use the scope, and we'll create something

  • on the scope called charts that it

  • will use to pull the charts from.

  • So we're no longer stuck inside of HTML world

  • that's sticking with expressions.

  • Angular allows, now we can actually

  • throw in Vanilla JavaScript objects and code.

  • So I'll be using D3 inside of here

  • to create an array of 10 charts.

  • Inside of each of those charts, each of those charts

  • will have 10 elements of random data.

  • This all right?

  • OK.

  • Sweet.

  • Now we've got all these charts.

  • They've all got their own random data.

  • I'll also make these a little smaller.

  • Cool.

  • Maybe give them 100.

  • Cool.

  • So we're on a pretty good roll here.

  • But now, wouldn't it be cool if actually

  • all of our donut charts were responsive,

  • so that whenever we resize the page,

  • all the donut charts would update accordingly,

  • and there would only always be, say, 10 donut charts

  • on the line.

  • So to do that first, we'll need ng-style,

  • and this basically allows us to dynamically apply styles

  • to our directives.

  • Wow.

  • maybe not 100.

  • We'll just say 10 for now.

  • OK, cool.

  • And that's not so bad, but it's not great either.

  • We'd really like it if they would all

  • change their size, too, whenever we resize the window.

  • Also change these to be percentages.

  • So we need our directive to update in some way, whenever

  • it's containing width and height changes.

  • So to do that, we'll need to do scope.watch, and then

  • give it a function that returns the width

  • and height of the containing element.

  • And whenever the return value inside of here changes,

  • the second callback will be fired.

  • And so this will handle resizing our donut chart.

  • I see some closed eyes.

  • What's up?

  • Ah, where?

  • Width, client, height.

  • Thank you.

  • Good call.

  • So yeah, so inside of here we'll do everything

  • that we'll need to change whenever the client width

  • and height changes.

  • We'll also need to update the width and height

  • to be those new values.

  • And now, we'll also need to take all the things

  • in our donut chart that depend on the width and height

  • and put them now inside of this callback, because all

  • those things will need to be updated

  • when the width and height changes.

  • So just going down from the top it

  • looks like min also depends on width and height.

  • And the arc, the arc's inner and outer radius

  • also depends on min, which in return, depends

  • on width and height.

  • It also looks like the SVG needs to be updated

  • when the width and height changes.

  • And also, this inner group that will translate the donut chart

  • into the center needs to be updated

  • whenever the width and height changes.

  • So we'll give that a name right now.

  • We'll call it G, and update it instead,

  • inside of the scope.watch when with width and height changes.

  • So I think that's everything.

  • Whoa.

  • What did we forget?

  • Oh.

  • So whenever it first loads, it looks

  • like they're all set to 100 by 100.

  • But the client width and height changes,

  • and we never get those updates whenever it happens.

  • So we actually need to also tell Angular,

  • hey, the window resized.

  • Someone resized the window.

  • Go check if anything on the scope changed

  • and run all of those associated watches for the client, width

  • and height.

  • So that's actually a simple fix.

  • We can just do scope-- inside of the controller,

  • we can do scope.-- Not scope.

  • You can have it depend on the window,

  • and watch for resize events on the window, and tell Angular,

  • hey, check for changes.

  • Whoa.

  • How's the method on?

  • Oh.

  • So we forgot to wrap our window inside of the sort of Angular

  • version of jQuery, and to do that we'll

  • have to do Angular.element.

  • Ah.

  • There we go.

  • So it's kind of working, but still, the radiis

  • are not updating.

  • So actually, we also forgot to apply the arc to the path.

  • That was the other thing, that depended

  • on something that depended on the width and height.

  • So the arc depended on a min-- I'm sorry,

  • the arc path depended on the arc generator,

  • the arc generator depended on min,

  • min depended on width and height.

  • So we'll need to actually take that, you see this right here,

  • and add it to our watch for the client, width and height.

  • Also need to give it a name, if it doesn't have one yet.

  • Cool.

  • Now we have dynamically resized, responsive donut charts

  • in Angular.

  • [APPLAUSE]

  • So the next thing you probably might want to do

  • is have your data update.

  • Maybe we're getting a live feed from some data source

  • and we'd like the donut chart to always be adjusting or adding

  • new data points.

  • Well, to do that, we'll first need the arc function.

  • And I've included the reference to Mike Bostock's

  • original demo, which describes how this works.

  • But for now, don't so much worry about the details.

  • Just know that it will be responsible for transitioning

  • our arc paths from one configuration to another.

  • You also need to watch for changes to the data,

  • and that's what this does.

  • Any time the data changes, this functional will run.

  • And in it, the arcs will be transitioned in or out,

  • and so for arcs.enter, all of this

  • will happen when there's more data in a pie chart

  • than there was before.

  • Similarly, for arcs.exit, all of this

  • will run whenever there's less data in the donut chart

  • than there was before.

  • And these will be run for any past data pairs that

  • will remain in the chart between the transitions.

  • So that's good.

  • But we also need some way to sort of test our little demo.

  • We need some way for the data to update inside of the directive.

  • So for that to happen, I just have this little snippet here.

  • So any time anyone clicks on the SVG run,

  • enter the Angular world, essentially saying, hey,

  • after I do all these things inside of here,

  • check for changes on the scope.

  • And in this case, we'll be changing the data

  • on the directive.

  • Just some random new data.

  • Oh.

  • That didn't work.

  • Why did it not work?

  • Do we have an error.

  • Ah.

  • So I forgot to-- since now the piece of code

  • that is responsible for adding or removing arc paths

  • is inside of scope.watch data, we

  • need to make sure that we don't do any of that outside of it.

  • So, in this case, we have these arcs, this arc selector,

  • and we're binding the data, when it really

  • is not responsible for it outside

  • of the scope.watch data.

  • So I'll just remove it.

  • And it may be somewhere else, but I think that's good.

  • Sweet.

  • So now we have these transitioning donut charts.

  • They start out with no data, they get data, they animate in,

  • and they look awesome because they're animated.

  • People love things that move.

  • So now, wouldn't it be cool if, for whatever reason,

  • we wanted all of these donut charts to share the same data.

  • We wanted it so that when clicking on one-- well,

  • actually, let's press the test if we can click on one

  • and update it.

  • We haven't done that yet.

  • So I can click on one donut chart.

  • Its data is being updated from the code that I've just added.

  • Every time I click, scope.data is being set to some new value.

  • Whoa.

  • That kind of looks cooler.

  • So yeah, we would like the data to be shared,

  • so just as a contrived example, I'll

  • just add some new variable to the scope.

  • I'll call it Our Data and just copy what we had up here.

  • I'm creating a chart.

  • And now they'll all just use that same shared

  • object, Our Data.

  • Sweet.

  • They all have the same data.

  • When I click on one, they all-- oh, they don't all update.

  • So this is sort of a gotcha when using ng-repeat.

  • ng-repeat will create a new scope

  • for all of your different directives

  • that use the ng-repeat.

  • So if you're familiar with object-oriented programming,

  • particularly in JavaScript using the prototype chain,

  • if you have an object that is an instance of some parent class,

  • if you set a variable on it to some new value,

  • that property will be that new value,

  • and it will not overwrite the parent.

  • And that's exactly what's happening here.

  • We need some way to prevent our data from being overwritten

  • on the scope for the parent property.

  • And so one trick to do that is to just use sort of a shared

  • object, an additional object on the parent scope

  • that will never get overwritten by us, on any of the child

  • scopes.

  • Also, you need to update it in our directive.

  • Oh no.

  • The worst error is no error at all.

  • I called it charts now.

  • Ah.

  • I don't have it called charts.

  • I deleted this.

  • They had this up here.

  • Charts, actually, will still be on the scope.

  • Oh no.

  • The demo gods will not allow.

  • I'll just chart our Our Data.

  • I'll leave that there for now.

  • Our Data.

  • Sweet.

  • So now they all share the same data, so when I click on one,

  • it'll be updated across all the donut charts,

  • or however many we decide to have.

  • Maybe we'll make them 140 high, and give them 100 of them.

  • Whoa.

  • So that concludes the talk.

  • I went over a lot, so if you feel confused, that's OK.

  • As long as you feel compelled to now combine D3 and Angular,

  • I'm happy.

  • I guess now, let me close and go back to my slides,

  • if I can find them.

  • So now it's time for Q&A, if anyone has any questions.

  • Is now a good time for QA by the way?

  • OK, what, I'm sorry.

  • AUDIENCE: [INAUDIBLE]?

  • VICTOR POWELL: So it's on GitHub if that's what you mean.

  • It'll be after the talk.

  • You can download all the demos and the ones we went over.

  • AUDIENCE: [INAUDIBLE]?

  • VICTOR POWELL: Oh yeah, I'm sorry.

  • To repeat the question he asked-- Oh,

  • I don't need the mic.

  • Just to repeat the question, can I

  • put up some of these directives on GitHub?

  • They will all be available online after the talk.

  • You can go and fork the repo or make contributions.

  • I know that some people have been talking

  • about putting together more comprehensive, a collection

  • of Angular and D3 directives, and there are actually

  • some already-- Brian, actually, put together

  • a great tutorial that walks through all of this.

  • But there are alternatives like Dangle--

  • I think Dangle, is that the right--

  • But I think a lot can be done, and a lot of improvement

  • can be made.

  • So I mean I don't know if I could stand up and volunteer

  • to do that, but I definitely think

  • there's a lot of value that could be added from doing that.

  • Next question.

  • AUDIENCE: So there appears to be some overlap between what

  • Angular can do and what D3 does.

  • So, for example, I saw the bar of the code that

  • was in the link function was creating elements in the Dom

  • and applying style to them.

  • And [INAUDIBLE] attributes.

  • And it appears to me that part of that

  • can be created in Angular templates,

  • but we can add those repeated G elements inside the template.

  • So is it stuff that's been tried are the advantages of this

  • [INAUDIBLE] to do that?

  • VICTOR POWELL: --indicated doing so.

  • I mean there's a million ways to skin a cat, as the cliche goes.

  • If that's a cliche.

  • I don't know.

  • I prefer to use D3.

  • It's where I have already a lot of domain experience,

  • and I'd like to continue using it.

  • But that's not to say it's the only way.

  • But I don't think D3 will be able to be removed

  • from the equation completely, because I think

  • it adds so much in terms of additional functionality,

  • helper functions that transform your data in a very

  • convenient way.

  • BRAD GREEN: Victor, we're actually

  • going to hold off on Q&A and do a couple of lightening talks,

  • and then do Q&A with you, Brian, Igor at the end.

  • So Brian's going to come up, and I

  • think he's talking about dependency injection.

  • Is that right?

  • So he'll be really quick, like lightening.

  • Look how fast he's walking.

  • He's already lightening.

  • BRIAN FORD: Just a minute.

  • So I'm Brian.

  • I work at Google on the Angular team,

  • and I'm giving a short talk about-- So

  • this is going to be a really, really short talk.

  • OK.

  • So Angular uses DI, and one of the cool things

  • that you can do in DI, or Dependency Injection,

  • that you can get a hold of some components

  • and then modify it and put it back in the system

  • and let Angular do its thing with it.

  • So here I have a really boring Angular app.

  • It's just two forms, and it cotinates together,

  • their output.

  • But what we can do is we can use this configure function

  • of an Angular module.

  • We can ask for a dollar provide, and dollar

  • provide has this method decorator where

  • you can ask for a scope-- or sorry.

  • You can ask for some service, so we can answer for,

  • for instance, the root scope.

  • It gives us this function where whatever we return back,

  • Angular will use as the root scope.

  • So what happens here is dollar delegate is root scope.

  • They're equal.

  • And we can now change root scope somehow.

  • So what I'm going to do is I have this little helper

  • function that I wrote down here called timerify.

  • This takes a function and returns a new function that

  • first starts the timer, then runs the original function,

  • then stops the timer, and then logs the amount of time

  • it took to do whatever it was that the original function was

  • doing.

  • So using this, we can actually time dollar apply on the root

  • scope, and we can see how long the digest cycle takes,

  • in effect.

  • So let's see what this actually looks like here.

  • So if I refresh this, we see 10 milliseconds, type stuff in.

  • Angular's pretty fast.

  • So that's kind of cool.

  • And this is actually the same trick

  • that battering, the Angular debugger extension

  • uses to get into Angular internals and mess

  • around with it.

  • So that's actually the whole talk,

  • the code and the short explanation is on GitHub,

  • btford/-- Brian talks about decorators,

  • doesn't he in the repo?

  • And that's it.

  • [APPLAUSE]

  • IGOR MINAR: So hi everybody.

  • My name is Igor.

  • I'm from the Angular team.

  • And what I would like to talk to you

  • about is about the process we use to handle PRs,

  • and kind of demystify what is happening when you send us

  • a PR, and how is it being handled.

  • So you work on the Angular application,

  • and unfortunately, you come across a bug.

  • Maybe it looks uglier than this one, or in a better case,

  • you have an idea on how to make Angular better.

  • Way better.

  • And naturally, you go to GitHub, and what you

  • notice there is that Octocat has only five legs.

  • Like I drew eight, because I thought Octocat, eight,

  • but it has only five.

  • Go to GitHub and check it.

  • You fork the project, you craft your change,

  • and you send us a PR.

  • And then you notice that the PR lands in our queue,

  • and there is like a million other PRs there.

  • And you start to wonder what's going on.

  • Do these people handle those PRs?

  • Does anybody ever look at them?

  • Well, the good news is that we are looking at them.

  • But there are so many of them that we

  • have to develop the process on how to handle them.

  • And I'm going to talk to you about this process

  • a little bit.

  • So step one of the process is you sending us the PR.

  • We covered this already.

  • The PR lands in our queue and there's a brand new shiny PR.

  • The next step is triage.

  • So what we do is once a day, we sit around a table

  • and all of us just hammer on GitHub

  • and look at the new stuff that just showed up,

  • all the new issues, all the comments, all the PRs,

  • and try to triage them.

  • During the triage, we review things.

  • We try to reproduce bugs or try to reproduce

  • the bugs you're trying to fix.

  • Label things into categories so that we have a better

  • understanding of what is it that you're trying to do,

  • and what the change is about.

  • And then we move things to milestones,

  • just so that we schedule when we're going to deal with this.

  • What these milestones are?

  • Well, ideally we try to merge things instantly.

  • But it's not that common that the change

  • is ready to be instantly merged.

  • And it's going to be obvious why in a little bit.

  • So it's more common that if it's an important backfix,

  • we schedule it for the current iteration

  • or for the next iteration.

  • Otherwise, it goes into a midterm milestone,

  • which we pull things out during our iteration planning.

  • If we don't have enough information about what is it

  • that you are trying to do, or if it's an issue

  • and it's not clear what the issue is,

  • we have a milestone called purgatory

  • in which we try to gather more information before we

  • decide what to do with the issue.

  • If the pull request is trying to do something

  • that we are not interested in just yet,

  • and we know that it's going to take a lot of work

  • to get it into the master, we put into ice box.

  • And hopefully, we'll some time get to it.

  • I'm not sure when, but we have this milestone because we

  • try not to reject PRs that seem to be valid,

  • but they are just not quite there yet

  • and won't be for a long time.

  • So Pro tip number one.

  • If you are sending us a PR, aim for instant merge.

  • What does this mean?

  • Ideally, it should be a backfix.

  • It should be a small change with good test coverage.

  • You should sign the CLA.

  • There is a script that bugs you if you don't sign the CLA,

  • and the CLA process is super simple.

  • And it should be obviously what you are trying to fix.

  • Write a good description, write a good comment message.

  • These are the best changes that we can easily get into master.

  • If we can do an instant merge, then

  • during iteration planning we schedule

  • the PR to be handled during the week.

  • And during the week we review it more thoroughly.

  • We provide more feedback on what is it that it needs.

  • And either wait for you to make the changes,

  • or we make changes ourselves and merge the change in.

  • This is done after all of our check boxes are checked.

  • The tests have to be there, the documentation

  • needs to be updated if necessary.

  • We need the CLA, and many other things.

  • All of these requirements are upline in the contributing

  • documents.

  • So this is on GitHub contributing.md.

  • You can check it out.

  • Pro tip number two.

  • If you're making a big change and you're

  • going to spend a lot of time crafting this PR,

  • please open an issue first.

  • This will allow us to look at it and give you

  • instant feedback, if it even makes sense to send us a PR.

  • Often people send us PRs, and they don't belong to the core.

  • We want the core to stay focused on the things

  • that only core can provide, and all this nice-to-have features,

  • we provided it through extra modules.

  • So, if you have something in mind

  • and you know that it's going to take a lot of time,

  • create an issue first.

  • Step four, done.

  • At least you think you're done, but the PR

  • is far from being done.

  • Step four is actually continuous integration.

  • By now, we ran your tests already,

  • because Travis-- we have this set up

  • with Travis that will run the tests whenever

  • you submit the PR.

  • But once we merge, we run the test

  • one more time just to send it and make sure that everything's

  • OK, no tests are being broken.

  • We actually currently run two set ups.

  • We have Jenkins on our own CI server.

  • And we have Travis with [INAUDIBLE] Labs

  • that seems-- like that's something

  • that we're trying to completely migrate to.

  • But it's a complicated set up, and to right now, we

  • run both just to be sure that we are not without the CI server.

  • But hopefully, everything's going to go well.

  • And we get step five, continuous delivery.

  • Not many people know about this.

  • But what happens is when the change gets merged into master,

  • we create a build and we push the changes

  • to the recommendation side.

  • So if you are making changes to the documentation,

  • those changes will be available right

  • after the change is merged.

  • We want this so that people can benefit from documentation

  • changes as soon as they land in master,

  • so that they don't have to wait for a release.

  • Another thing that we also do is once a build is created,

  • we push it to bower.

  • We want people to start using the bleeding edge of Angular

  • more, and that's why we push to bower after every comment.

  • So every comment that lands in master,

  • we create a build out of it, we push

  • it to bower with a pre-release [INAUDIBLE] version,

  • and you can fetch it very easily and start using it.

  • This is not as crazy as it sounds

  • because this is what we do at Google already.

  • We take every comment that lands in master,

  • we sync it into Google, and we run it

  • against all of the applications that use Angular at Google.

  • This gives us very fast feedback on whether there

  • is a breaking change, or basically,

  • if everything's fine.

  • And if everything is fine, then we

  • sync this change into the internal repository, where

  • within a few hours, all of applications will pick it up

  • and will start to use it, some even in production.

  • Pro tip number three.

  • Aim for greatest coverage.

  • The sooner we can discover issues,

  • the sooner we can fix them and can

  • avoid issues in a later phase, which

  • would mean like we wouldn't have to revert the comment,

  • or fight those fires.

  • So if we have a good coverage for all of the changes,

  • this can avoid a lot of hassle later in the process.

  • Pro tip number four.

  • Be mindful of breaking changes.

  • Like during stable releases, we really

  • don't want breaking changes.

  • And if we see that something has a breaking change,

  • it's not going to make it in.

  • We have an unstable branch which will be opening for 1 to 3

  • very soon.

  • And we have a process for handling

  • these breaking changes.

  • But most commonly, we just don't want breaking changes.

  • Step number six is at release.

  • During the release, we generate a change log.

  • And the way we generate it, we take the comment

  • messages that landed in-- from comments that land in master,

  • and we have a script that will just generate it.

  • This is why we have this pretty strict format for the comment

  • messages, so that we can just generate the change

  • log, because otherwise, it's so much hassle to create release

  • notes for every release, especially if we

  • are trying to release once a week.

  • Pro tip number five.

  • When you write a comment message, write it in a way

  • that you would love to read it, or you

  • would love others to read it.

  • This means describe the fix or the issue that you are doing.

  • If it's a feature, make sure you describe what it does.

  • But provide more in-depth explanation probably

  • in the documentation that is associated with the PR.

  • Next thing we do is we push the bits to code AngularJS.

  • This is just an archive.

  • It's not a CDN.

  • I often see people use the code AngularJS in flunkers

  • and and JS fiddles.

  • Use the CDN URL better.

  • This is really meant just for an archive, and it's not a CDN,

  • but it contains all the artifacts,

  • including the documentation.

  • So if you want to see what the documentation looks

  • like at some version, you can go there and see it.

  • Next what we do is we take all the build artifacts and push

  • them to bower, this time with the proper release versions

  • so that you get whatever Angular 1 through 9,

  • or whatever it is that we are releasing.

  • And we also push the artifacts to Google CDN

  • so that you can get them to clients as soon as possible.

  • We have Angular-seed.

  • We push the bits in there, and we

  • have the tutorial which we keep up-to-day,

  • so we also update that on every release.

  • And that's it.

  • Like now your PR is in Angular, it made it better,

  • and we are very thankful.

  • And we are hoping that you're going

  • to send us more PRs that are really high quality.

  • Thank you.

  • [APPLAUSE]

  • So I think we're going do Q&A now, right?

  • And one more announcement.

  • We have a bunch of food left over, and we have boxes,

  • so if you want to take some food home, feel free to take some.

  • Yeah, we'll take questions now.

  • Victor and Brian.

  • Sorry.

  • AUDIENCE: Hey, thanks for all the talks guys.

  • Quick question for Brian.

  • Can I use your decorator for route provider

  • and do something on [INAUDIBLE] change?

  • Get a hold of providers, can you?

  • IGOR MINAR: Get hold of providers, no.

  • The providers are available only during the run phase.

  • But for run changes, we have events.

  • You can listen on run, change, start event, and just handle

  • whatever you need to do there.

  • AUDIENCE: This is in line with my question from last Meetup.

  • On every oil change I want to select

  • kill all the Ajax sequence from the previous page,

  • and kill the timers, and all that.

  • So I was wondering if this could be just a decorator that no one

  • else has to--

  • BRIAN FORD: Oh, OK.

  • Oh.

  • AUDIENCE: Well, I'll continue with the events.

  • But I was hoping this was handled without anyone else

  • having to do anything.

  • Thank you.

  • AUDIENCE: [INAUDIBLE].

  • I just want you if there is a couple

  • more ways to make sure what I'm doing is sufficient.

  • More often than not, I see that I put a console log statement,

  • I see too many things coming up late.

  • Am I doing something might reduce efficiency or something?

  • BRIAN FORD: Often, when you're trying to debug something,

  • you see--

  • AUDIENCE: Yeah, let's say, for example, I

  • was writing a validation event, and then I see that-- Yeah.

  • Is it watching on too many changes or no?

  • BRIAN FORD: We are working on better tools to answer that.

  • I agree, right now it's not easy to diagnosis, for instance,

  • why is something slow.

  • We're working on it.

  • And you can use techniques like that to count how many times.

  • You wouldn't use-- decorator is more like of like a system.

  • This you would probably want [INAUDIBLE].

  • Louder?

  • There we go.

  • I'll just steal this.

  • So if you want to answer the question

  • of is a specific watcher slow, you

  • could use a similar technique where

  • you're instrumenting the function

  • and adding, and stopping a timer.

  • But this technique of using decorator

  • is more for like system-wide changes.

  • Like if you want to change something

  • in the entire DI system inside of Angular.

  • Right now, it's perhaps a little bit hard

  • to kind of drill down and decide which things are useful.

  • But we're working on better tools for that as well.

  • AUDIENCE: Thanks.

  • BRIAN FORD: Sure.

  • AUDIENCE: My question's about D3.

  • So donut chart is really cool, and you

  • can make as many donut charts as you want,

  • and you can resize them.

  • What is your preferred method for testing your D3 directives,

  • because they can overlap, they might not update with data.

  • A lot of things could happen to them.

  • VICTOR POWELL: That's a good question,

  • and it's a hard one to answer, but currently my CI environment

  • is my eyeballs.

  • For UI, it's very hard to come up with good testing,

  • in my opinion.

  • Maybe there could be better tools or better tools

  • that I could become more aware of.

  • But it's easier for me to just get immediate feedback just

  • from seeing if it works or it doesn't.

  • IGOR MINAR: I came across an interesting tool called Huxley,

  • which is a web driver-based testing framework.

  • And what it does, it take screenshots and compares them,

  • so that you can use that for testing UI stuff.

  • And actually, like it sounds crazy,

  • but the more I think about it, it's pretty cool.

  • Like Huxley, check it out.

  • Huxley, yeah.

  • I think it's done by Facebook.

  • BRIAN FORD: So it's pretty easy to test to things

  • like does this have a given width or height

  • or some certain property.

  • But really, if you want to test that something doesn't overlap

  • or something that really looks like that,

  • tools that take screenshots and [INAUDIBLE] them, or really,

  • I think, the only--

  • AUDIENCE: Well, the way this tool works

  • is that you take a screenshot that you're happy with,

  • and then you take it every time you make changes.

  • BRIAN FORD: Right.

  • Yeah, precisely.

  • AUDIENCE: And when there is a change that

  • doesn't match the original screenshot,

  • then it's something that you should look at.

  • And the new updates of the screenshot's

  • a part of the review process.

  • So check it out.

  • It's pretty cool.

  • BRIAN FORD: I've seen it.

  • And there are similar tools, though,

  • like it's not a new idea.

  • But you can do something like that in your CI environment.

  • So that way you still would catch

  • those sort of regressions.

  • AUDIENCE: Huxley, yeah, with H.

  • AUDIENCE: A question about data feeds.

  • I'm still kind of new to Angular,

  • and one thing that I learned early on

  • is this idea of a promise, where basically you've

  • got some data out there and it'll come sooner or later.

  • Should I use Angular functionality

  • to deal with data that might be coming sooner or later,

  • or should I rely maybe more on D3,

  • assuming D3 has that functionality

  • to deal with data which might be coming sooner or later.

  • BRIAN FORD: Or never.

  • AUDIENCE: Or never.

  • IGOR MINAR: I don't know.

  • I don't know if D3 has promises.

  • VICTOR POWELL: Mostly, that's an issue

  • of getting your data before it goes into the visualization.

  • And even though D3 does offer a suite of utilities

  • for making that easier, like D3.CSV and TSV,

  • I would recommend pulling all of your data in through a service,

  • and then using that inside the controller,

  • and then setting the data you got from the service

  • on the controller, on the scope, and then your D3 directives

  • will just plug into that.

  • So your D3 directives shouldn't care

  • where they're getting their data.

  • Just that they have data.

  • AUDIENCE: OK.

  • Thanks.

  • AUDIENCE: This is a question for Victor.

  • Your comment about there's many ways to skin a cat.

  • Just thinking that I'm more familiar with Angular than D3,

  • but it's clear that there is overlap

  • in the kind of binding area and things like that.

  • And you said you came from your domain-specific kind

  • of knowledge, that you went more with the D3 route.

  • Have you run across anything where

  • maybe in blending the two together

  • it overrode your domain dominant mode of working, where you

  • found, perhaps, for stylistic or performance reasons

  • there was a good reason to change

  • the way that you were working?

  • VICTOR POWELL: I haven't really run

  • into too many issues like that.

  • I feel as long as you do a, if you're

  • very explicit about keeping the boundaries,

  • that whatever goes inside of your directive,

  • your visualization directive should only be related to D3,

  • then you don't really have to worry

  • about them clashing too heavily.

  • AUDIENCE: And again, just more on D3.

  • Did you look at other things that are out there,

  • or how do you compare it to other things

  • that are out there, and why D3 versus--

  • VICTOR POWELL: So the good thing about all

  • of what I just showed you is that you can replace the D3

  • parts with whatever you'd like.

  • You could manipulate the Dom directly if you really

  • wanted to, but I would advise against it,

  • and instead using a library like D3.

  • But it's not the only one out there that does what it does.

  • So you're free to use whatever you'd like.

  • My personal bias is towards D3.

  • AUDIENCE: Why?

  • VICTOR POWELL: Just because with D3 I can write less code,

  • and code that I can come back to later

  • and have a pretty good understanding of what

  • I wrote earlier.

  • BRIAN FORD: I would say one thing

  • that I think D3 does better than similar like SVG libraries is

  • that it has concepts that compose together well.

  • Whereas other libraries are more draw me a bar chart.

  • D3 gives you kind of these different layouts

  • and these things and lets you build up

  • something complicated out of smaller parts.

  • VICTOR POWELL: I like to think about it as a meta library.

  • I wouldn't use it to just give you an existing bar chart.

  • You would-- [AUDIO DROP]

  • AUDIENCE: So I have a question for Victor.

  • I was wondering, I'm a big fan of D3,

  • but have you found any limitations

  • in using Angular for D3?

  • And then my second question is using Angular,

  • do you still find it's necessary to use

  • NVD3 to have it modularized?

  • VICTOR POWELL: Can you say that again?

  • AUDIENCE: So have you found any limitations with using D3?

  • So did you have the full suite of D3 library available to you?

  • And then second question is there's NVD3 JS, which makes it

  • so that you can modularize your D3.

  • Do you find that Angular allows you the ability

  • to modularize without the need of NVD3?

  • VICTOR POWELL: I would say-- I don't actually

  • have a whole lot of experience with NVD3.

  • I prefer to have more flexibility,

  • so I tend to avoid libraries, like NVD3, or what have you,

  • or any other sort of collection of existing D3 libraries.

  • When I want to use D3, it's not because I

  • need a bar chart or pie chart.

  • It's because I want to do something

  • that hasn't been done yet.

  • So it's not really a problem I can address.

  • Coming back to Angular running into limitations,

  • I mean I haven't really run into any major gotchas,

  • except for the scope with ng-repeat that I mentioned

  • earlier.

  • I'm sure there are other areas.

  • I haven't fully exhausted every possible combination

  • of D3 and Angular, though.

  • So there's probably those gotchas out there

  • that I have yet to come across.

  • AUDIENCE: I have a question about-- here-- the question is

  • about Angular is about manipulating Dom structures,

  • and D3 is also manipulating, but it's inside SVG.

  • Have you ever tried to use Angular markups inside the SVG

  • markup so that it can directly driven

  • by the binding or the brackets inside SVG?

  • VICTOR POWELL: Well, first off, I

  • want to clarify that D3 is not only just for manipulating

  • SVGs, even though that is commonly used with SVG.

  • To address your second question, that

  • was like the comment that was asked earlier

  • at the end of the talk.

  • There are other ways of creating data visualizations,

  • but I think there is always going

  • to be at least some need for D3 along the way.

  • Maybe in the future, the features that D3 provide

  • wouldn't be in some monolithic single framework as it is now.

  • You can already do this in some extent

  • when you compile it on your own.

  • You could pick out the features you're interested in.

  • But it does more than just manipulating the Dom.

  • It gives you a whole suite of tools

  • for manipulating data that are useful in data visualizations.

  • AUDIENCE: So That is actually, it is possible

  • directly using Angular to manipulate the SVG Dom so

  • that you can change based on the data definition or data

  • changes, right?

  • VICTOR POWELL: I'm sorry.

  • AUDIENCE: For example, I have some paths, some rectangle

  • defining the SVG markup, and I have some of the property

  • directly binded with Angular's property,

  • like brackets, using brackets to bind with Angular property.

  • So that when Angular's property got changed,

  • the value in the SVG's definition got changed too,

  • with it.

  • So it is possible to do that without--

  • VICTOR POWELL: I think you just answered your own question.

  • AUDIENCE: For example, I'm defining kind of a path in SVG.

  • We are providing several coordinates

  • in the D property of the path's element.

  • Without using D3, are you directly

  • referencing one property from a scope of the Angular.

  • So that when the property, Angular's scope got changed,

  • the paths got changed in the SVG, too.

  • So that it doesn't have to actually use the D3

  • to manipulate the Dom without using--

  • I mean in your presentation you defined a directive,

  • so do you watch the data change?

  • And then using the D30 enter exit update

  • to actually update the SVG Dom.

  • I don't use this part.

  • I directly referencing the data from the scope.

  • VICTOR POWELL: Can you repeat that?

  • BRAD GREEN: So he's just asking if there's

  • anything special about the SVG element

  • and the way it's rendered that would prevent you

  • from interplating an Angular scope within that.

  • VICTOR POWELL: Oh, OK.

  • That's an easy question.

  • No.

  • Because the SVG inside of the Dom

  • is just like any other Dom element.

  • IGOR MINAR: We do have tests that

  • verify that the data binding works with SVG notes.

  • And if there are some issues, then please

  • file them with all the bugs, and we definitely want to fix them.

  • AUDIENCE: I had just a short idea

  • that I can-- Is it common to use this other thing

  • with like streaming data?

  • Saying if some backended streams data to the front end

  • to [INAUDIBLE].

  • VICTOR POWELL: You're saying is that possible, or?

  • AUDIENCE: No.

  • If this is like a common use case.

  • VICTOR POWELL: Yeah.

  • You could use it for doing that.

  • If you do it the way I described,

  • the directive shouldn't really care

  • where it gets the data from.

  • So it really shouldn't matter.

  • You could have a service that's pulling data dynamically

  • from some API that it's just updating.

  • And then the controller would be responsible for updating

  • the data on the scope and the directive

  • will just update automatically.

  • You could put the web sockets inside of a service

  • or maybe there's already someone might have already written

  • something that does that that allows

  • Socket.IO to work in Angular.

  • But I think the directive really should

  • have no opinion where the data comes from.

  • AUDIENCE: Thanks, first of all, for the talks.

  • They were great.

  • VICTOR POWELL: Thanks.

  • AUDIENCE: My question's about interceptors.

  • So what are some other examples where you would use it,

  • besides the timing, either execution to run your code?

  • The first thing that comes to mind,

  • perhaps, is maybe role-based access control.

  • Would that be appropriate use of interceptors in Angular?

  • I'm very new to it, so I'm just kind of curious as to what else

  • you could do with it.

  • BRIAN FORD: Sure.

  • It was decorators is what--

  • AUDIENCE: Right.

  • BRIAN FORD: That's OK.

  • But interceptor's actually a good way of thinking about it.

  • I like that.

  • AUDIENCE: Sorry, I always con--

  • IGOR MINAR: But we also have interceptors--

  • BRIAN FORD: Yes.

  • But it's important, because there also

  • is this thing called interceptors with HTTP

  • so you can intercept responses and incoming and outgoing.

  • But it's important to distinguish between those.

  • So you probably wouldn't use this sort of technique

  • for something like that.

  • You probably have some custom service

  • that you wrote that interacts with your model data.

  • But if you wanted to, for instance,

  • say I'm going to shut down all HTTP requests across the board

  • if a user doesn't have this thing, like dollar HTTP doesn't

  • have such an ability.

  • But you could hack your own little API onto it

  • by saying give me dollar HTTP, and we're

  • going to change how it works so that way it

  • does something else.

  • The idea is that you can change existing services

  • by kind of patching their properties.

  • AUDIENCE: Wait.

  • Can't you use the HTTP backend service, like you do in--

  • BRIAN FORD: There are a lot of ways you could do it.

  • I was looking kind of for an example.

  • Yeah.

  • But that, perhaps, might not be the best way to do it.

  • But yeah, certainly.

  • IGOR MINAR: The important thing is

  • that whenever you use decorators,

  • ensure that the API stays compatible.

  • Because as soon as you monkey patch

  • the object in a way that is not compatible,

  • then you might run into issues with components

  • that expect whatever service it is that you are monkey

  • patching to behave in originally.

  • BRIAN FORD: Yes.

  • It's a very powerful tool, and you

  • have to be responsible and stuff.

  • VICTOR POWELL: I just wanted to make one small point,

  • especially with role-based access control.

  • You really don't want to be relying

  • on doing that on the client to begin with.

  • I think you mentioned that a little bit, actually.

  • Fair enough.

  • So, responsible.

  • AUDIENCE: So I'm interested in the book you're

  • writing with Ari on D3 and Angular.

  • Could you talk a little more about what

  • you find that's interesting it it?

  • You know, sell it, as it were.

  • VICTOR POWELL: Well, the book isn't 100% done.

  • Most of the book, as is, goes through an instruction to D3

  • and an introduction to Angular.

  • But combining the two hasn't been fully

  • worked out in the book.

  • But it should be very soon.

  • Some of things it'll be going over, I went over in the talk,

  • or that will be going over in the book,

  • I went over in the talk.

  • But I don't want to give away all the secrets.

BRAD GREEN: OK.

Subtitles and vocabulary

Click the word to look it up Click the word to find further inforamtion about it