JOHN:
The kid can’t help it. He’s so damn excited about Star Wars coming out. Every time he reads something, he walks to my office. He’s like, “Dad!”
CHUCK:
Nice.
[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco and New York and LA get on JavaScript developers providing to put the salary and equity upfront. The average JavaScript developer gets an average of 5-15 introductory offers and an average salary of over $130,000 a year. You just can either accept an offer and go right into interviewing with the company and neither with that any continuing obligations. It's totally free for users, and when you're hired, they'll also give you a $2,000 signing bonus as a "Thank You" for using them. But if you use the Adventures in Angular link, you'll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired to get a $1,337 bonus if they accept the job. Go sign up at Hired.com/AdventuresinAngular.]
[Ready to master AngularJS? Oasis Digital offers Angular Boot Camp, a three-day, in-person workshop class for individuals or teams. Bring us to your site or send developers to ours classes in St. Louis or San Francisco – AngularBootCamp.com.]
[This episode is sponsored by Digital Ocean. Digital Ocean is the provider I use to host all of my creations. All the shows are hosted there, along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent. And their VPSes are backed on solid-state drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code “Angularadventures” you'll get a $10 credit!]
[This episode is sponsored by Telerik, the makers of Kendo UI. Kendo UI integrates seamlessly with both AngularJS 1.x and 2.0. It provides everything you need to integrate with AngularJS out-of-the-box bindings, component configuration and directives, template directives, form validation, event handlers and much more and yet Kendo UI tooling does not depend on AngularJS. So if you want to use it with Angular or not, that’s totally up to you. You could check it out at KendoUI.com]
CHUCK:
Hey everybody and welcome to episode 72 of the Adventures in Angular show. This week on our panel, we have Joe Eames.
JOE:
Hey there!
CHUCK:
John Papa.
JOHN:
Hello.
CHUCK:
I’m Charles Max Wood from Devchat.tv and this week, we’re going to be talking about Angular 2 Directives and Components.
Before we get too far into this, I’m wondering if you’ve done much with Angular 1, you get far enough down the trail you wind up writing directives. But I don’t believe that components are part of the vernacular with Angular 1 so can we get a definition of how things have changed from Angular 1 to Angular 2? And what we’re talking about, we’re talking about components versus directives.
JOHN:
I think we have different backgrounds on different technologies we’ve used, patters and frameworks, but in Angular 1, we have these things called controllers and that was our JavaScript. They had something associated with them which was HTML or the template. So that was the view – the template, the HTML was the view and then the controller was our JavaScript.
In Angular 2, we had this thing called the component which – it’s not exactly one to one like this but the way you think of it or how I like to think of it is the component contains the JavaScript against it like the controller logic used to put in our controller, you now put that into a component. But the component also has a template that is directly linked to it.
A component – it’s something that has JavaScript that will help you talk about a UI piece. It also has its HTML, its template. It also may have its own styles. So a component is something that is, in a quick nutshell, is something that’s reusable that you could basically plop somewhere on your page almost like a super powered directive from Angular 1.
JOE:
Super powered. [Chuckles]
JOHN:
Yeah, I noticed I put these super powered there because that’s like the super heroic framework from Angular 1.
CHUCK:
Uh-hm. [Chuckles]
JOHN:
I don’t know if it was intentional. Coupling of those are not but I know in Angular 1, you’d say ‘here’s my router’, ‘my route says when you go to this URL, it’ll run this component with this HTML and that kind of marry the two together.’ In Angular 2, what we say is ‘okay, my component and my HTML are a little more coupled together’ meaning this particular component is always going to have this particular HTML template and that’s how it works. Although I have heard ramblings of ‘hey, what if we’d wanted to support multiple templates for it?’ At this point, all I know of is it supports one.
JOE:
Right. And that’s just an interesting point/side note that Aurelia does supports multiple, right?
JOHN:
I believe so, yes.
JOE:
I think I was a contention point between Rob when he was on the Angular team with how that worked, but I think that was – it was a little bit different because Aurelia – the templates point at the component. In Angular 2, the components point at the template.
CHUCK:
So what – I still don’t completely understand why is that significant?
JOE:
I don’t know. I guess when you're a framework guy, it makes a huge deal. I wrote a demo a long time ago and Rob got on and rewrote it. I wrote it at Angular 2 demo, he got on and wrote it in Aurelia. It was a little tiny thing so really, it wasn’t that interesting but he explained the whole template pointing at the component and why that’s better and that allows the same component to be use as multiple templates.
JOHN:
That’s one of the things I agree. I’ve been doing frameworks for how many years and the one thing that always seems to make certain people really get their opinions in a twist is the whole ‘hey, should the view point to the controllers? The controllers point to the view? Should we be doing MVP? Model representers? MVVM? MVC? I don’t really give a poop is what I do. [Laughter] Other people can get upset one way or the other if they like but I just don’t think it matters in the long run. You deal with the pattern that’s dealt you and none of them are bad; they're all good so who cares? [Chuckles]
CHUCK:
Yeah, so I think the Mv*. It’s really only helpful for categorizing how you connect your data to your template. So if I’m talking to somebody and I’m saying I’m using a framework that’s MVVM then they get the idea that that thing in the middle is a view model, or an MVP is presenter. But when it comes right down to it, it doesn’t really matter what Angular 2 is if you're going to use it because yeah, you just use it the way that it’s designed to be used or break the rules deliberately where you need to.
JOHN:
Right. And just to be clear, we’re talking about Rob Eisenberg from Aurelia?
JOE:
Yes.
JOHN:
Rob’s a great guy, a friend of all of us. The one thing he’s great at is making awesome frameworks. I think Aurelia’s got some great things in there and how they connect, there’s definitely pros to saying, “Hey look, the template’s [inaudible] the controller.” There’s pros in knowing and saying, “Hey, the controller’s [inaudible] the template.” Both sides have pros, both sides have cons but I think to really get back to Charles’s point is what is a component? Everything’s moving towards a shift of we can create an element in HTML, something that we can just [inaudible] HTML view and say, “Hey look, here is our calendar thing. Here’s our Lord of the Rings list.” Whatever these things are, that’s our element and that element is self-contained and it contains all the things it needs to make something up here and be functional on the screen. That’s the idea of web components and that’s where components were modeled after for Angular 2.
JOE:
So I want to ask you something, John, and check if you want to chime in as well. The whole single component, multiple templates type of thing. Have you ever actually used that in a production application where you’ve been – I’ve got a single component and I do want multiple templates whether that’s in Angular 1 or in any other framework.
JOHN:
So the question is do I ever want a component that have multiple templates on it?
JOE:
Yeah, to be able to choose multiple templates. [Crosstalk]
JOHN:
I’ve had that situation happen to me twice in my career.
JOE:
That’s two times more than me. [Chuckles]
JOHN:
It’s very, very rare. One of the times was literally a demo; the other one was a production app but in the production app, I actually tried to talk them out of it but I lost. [Chuckles]
CHUCK:
So the way I see this is if you have different presentation for a component that may have different state to it, but then I may still be misunderstanding what the component actually provides you.
I’ve been authenticated or something and so I want to show people a lot more information or things like that. A lot of times you can push that up to higher levels of abstractions so that it’s actually in your authorization and not in your component. But yeah, I can see where people would think, “Oh, I really like to be able to conditionally show different information,” but I don’t completely see where you necessarily would either not be able to put that into the template – show this if this, show this if that, don’t show this if this. [Crosstalk]
JOE:
You can still use one template exactly.
CHUCK:
The other side of things is you have that authentication piece and so it does the check and then it just gives you the standard ‘you can’t see this because you’re not an admin.’
JOHN:
Let’s put it this way; Joe’s had it happen zero times, I’ve had it happen two. I’ve written thousands of these kind of things and that’s – it’s two out of all those. To be very blunt, this is a scenario – I’m not going to say nobody has this scenario. I believe there is a scenario for it but it’s one of those where if you didn’t have the ability to do that, you weren’t going to go home and cry about it.
CHUCK:
Right. There’s a reasonable work-around for it.
JOHN:
Yeah, it’s not a problem I have in my life.
JOE:
Right. And it’s much better if you just show in various different things, multiple states to just built it into the template.
JOHN:
And they are so completely different. I had this question come up where a friend of mine was building an app that had to work on a mobile device in Ionic and also in an Angular app for desktop. The UIs were really different but they wanted to share the controllers and the views. Then they backed off so now I just want the same controller for two different templates. I said, “Well, what are you showing in the UI?” Eventually, they backed off and the reason they backed off was the Angular app on the desktop was so dramatically different. Yes, they both showed a list of things but with a bunch of paraphernalia.
But the one of the phone, the list was so condensed there were two columns instead of 20 which in the desktop and all the other fields were completely hidden on the phone. At this point, you're so completely different and all the UI’s different, why are you even bothering? The logic isn’t even the same anymore. That’s when they just said, “You’re right. It doesn’t make sense.” Anything that was common, they moved over to a service or a factory and they moved along.
CHUCK:
I think the interesting thing here is – and this is something that I see working on Rails apps even without doing client side rendering one way or the other – a lot of people put in a controller in Rails, basically a conditional that sets up different sets of data for different states and then they tell it to render different templates or views based on that conditional, that same conditional. You look at it and it’s like, “No, this is two controller actions that do completely different things. They just happen to have similar function and you have that conditional that changes some of it.
At that point, why create this big, bloated component for your mobile view just because you want to be able to use it on your desktop view, too.
JOE:
Right.
CHUCK:
So because the concerns are different enough, yeah, split it up.
JOHN:
Let me ask you guys a question. I’m looking at an Angular 2 component right now and I was trying to think the other day what are the – not the essential things but what are the most common things that I’m going to associate with an Angular 2 component? I’m looking at the one that I’ve got here in front of me for the Angular 2 Tour of Heroes demo which people can check out on the docs in Angular.io. In that first component – I’m revising this right now – it’s got an [inaudible] app component. That app component is a class and it’s got a couple of properties and that’s it. But the key pieces for me are the component always has some properties that expose some kind of data that will be data bound on the screen like a title or a first name. But then I also seem to always have the app component directive – decorator right above it. So I’m decorating metadata about this component and I’m always telling it ‘where’s my template?’ And I like to point my templates so you get – you have a choice of templates. You can either do embedded string right inside either a JavaScript file of a TypeScript file, or you can point to an HTML file.
Sometimes I have styles and you can do embedded styles or you can point to your CSS file that’s an array. Then I’ve got a route config sometimes and this is kind of new thing that’s correct in here is routes are no longer centralized for your module because the modules – it has a different meaning now but we can define routes at a component level in Angular 2.
So I’m finding that I often have in a component properties to data bind to, a template to point to, sometimes styles and then sometimes I have routes that I define there and that’s different. What are you guys seeing?
JOE:
Basically everything that you see.
CHUCK:
Yeah, I’m going to admit that I haven’t done a whole lot with Angular 2 so I don’t know that I –.
JOE:
Well I know about the benefit of having a component for me. Now I have to pull it up just that I could talk and tell [inaudible].
CHUCK:
Yeah. Is there a link that we can put in the show notes for people [crosstalk]?
JOHN:
Yeah.
JOE:
How about the Tour of Heroes? That’s absolutely a great link to look at.
CHUCK:
Okay. [Crosstalk] Can we get a link to that really quick?
JOHN:
I will go get you a link right now and you can pop it up in there so people can see and follow along. [Crosstalk]
CHUCK:
Yeah. I know some people are listening in the car and so we’ll try and be explicit as we can. [Crosstalk]
JOHN:
No, they can pull up. [Crosstalk] No, no, Joe. No, no, no. [Laughter] I’m not getting sued by anybody today. [Laughter]
This is my personal repo but it’s basically the same. This is not the official Angular 1 by any means but it’s the same thing that we put together for Tour of Heroes. This is the exact [inaudible] I’m looking at right now. So if you want to click that one and follow along, it’s angular-2-tour-of-heroes repo up on the John Papa GitHub. That’s all on one word. And it’s at /source/app/app.component.ts. Those are for people in their cars who are trying not to kill themselves.
But looking at that, the weird thing for me is still now we’ve got routing in there because we generally would have a routing to find somewhere else in an Angular 1 app. Now we’re saying this component is – this happens to be the base component for the entire app, Tour of Heroes, this is where all the routes are being defined for the app component and it defines dashboard and heroes and detail for heroes. But theoretically, you could have on a larger app, a subcomponent which also defines routes as well.
In a way, I look at the component almost becomes what in Angular 1 was a module because it’s self-contained and our modules used to define routes. Then a subcomponent also might be like a sub-module in a way. This works because of the way module loading works and ES 6 and TypeScript.
JOE:
That’s an interesting way to look at it. As I look at the way the components work like this, I see it more like the problem with Angular 1 was that very few people did nested directives. Very similar do we see nested directives. Whenever [inaudible] said, “Hey, I’m going to do a directive for the entire view,” and then inside that, there’d be a directive for this panel, one for this panel, [inaudible] this panel. And then within that there’s a directive for this button and one for this drop down list, et cetera.
Whereas in Angular 2, we got nested components like React. We have a top level one that contains everything and then that, we break it all down and keep breaking it down, breaking it down. We really didn’t do that in Angular 1. I don’t know if you had a different experience when you built stuff in Angular 1 but I replaced an iOS [inaudible] that was not the way that we built stuff.
Directives were only a very bottom level thing.
JOHN:
This is why – I think you’ve seen in the past Joe that I have hinted that I’m not a huge fan of directives in Angular 1. The reason is not because of directives; it’s because of the way they were implemented and how painful they could be in Angular 1. Let me tell you, my experience is different and that’s – I don’t like nested directives in Angular 1 because I’ve dealt with [inaudible] where literally, people will have exactly what you said, they’d have a view, then they’d have a directive which had another directive which have another directive. It was like that Russian stacking doll. [Chuckles] The problem with Angular 1 with that – that’s generally not a bad idea, honestly.
Having things that are decoupled like that – they can work together or on their own and you can piece, [inaudible] and compose your objects. But in Angular 1, directives were much more difficult to work with than components are in Angular 2. So I think in Angular 2, that style lends itself much better. In Angular 1, I think it was just a lot harder to achieve and I’ve literally banged my head in [inaudible] worked with apps like that because it just hurt.
JOE:
Let me see if I can sum this up. You're saying you hated it in Angular 1, these nested directives? If anybody did do that, do three or four levels of nested directives, you hated it or you would’ve hated it if it ever happened. But in Angular 2, as you're seeing it, you're not seeing the same problem basically because of how the way Angular 2 is designed.
JOHN:
Yes. And not hated it so much as I called caution in to it when people did it seven levels. It was one or two who cares.
JOE:
Right.
JOHN:
Now, I think it’s easier to take components or directives in Angular 2 which we should define the difference between those and actually stack those inside of each other and nest them because of the way they communicate better with each other.
JOE:
Okay. I don’t know if you want to go on to the definition but I have a question about 1.5 and the new component function and what you think of that. Have you played with it?
JOHN:
I haven’t played with it but I’ve read about it.
JOE:
Okay. Close enough. Thoughts? [Chuckles] Does it address that issue? Your specific issue? I think in general, in Angular 1 directives were also very seldomly done. Most people just did controllers and they wrote directives infrequently.
CHUCK:
I’ll tell you; that was the approach that I usually took.
JOHN:
Yeah, and I honestly think that was a good approach. We’re not talking about this; I’ll speak for him here is that I think directives, while they're an essential piece of Angular, I think writing custom directives in Angular 1, you could actually write an entire app without a custom directive. It will be fine.
CHUCK:
Yeah.
JOHN:
And I don’t think that was an awful thing but I think that leads to some practices that are going to make things difficult for people in Angular 2 since we are componentizing.
JOE:
Right. Yup. It is funny. I sometimes feel a little nervous when I see a lot of people out there talking about learn and migrate, migrate your Angular 1 apps to Angular 2, do these things – don’t migrate because I feel like you don’t want to do that. You don’t want to migrate in that same way. You don’t want to say, “Oh, I got a directive. I’m going to [inaudible] the component.” If you get to that thought – I’m not saying that everybody’s making those same statements like, “Oh, you got a directive? Let’s just turn in to a component, be very easy.” But that is one thing that, in 1.5 with this components, your component functions doesn’t make the directives in 1.5 look a lot like components in Angular 2.
JOHN:
Yeah, it does.
JOE:
So if people are just taking their existing apps and turning their controllers into a component, and then their existing directives into the component, I think you're going to be missing out on a lot of stuff. Maybe that’s the only way you can get a rewrite to happen and you want to rewrite, you want to be in Angular 2 then that’s probably okay if that’s the only way, but if you don’t take the time to go through and just rethink some of the things that you're doing, I think you’d be missing out on a lot of the benefit.
JOHN:
I look at is as – it’s a nice little way to slide in. but I agree with you, I think you really need to think more about it because maybe this leads into what – how it was alluding to components and directives in Angular 2.
A component in Angular 2, to me, a lot of times on [inaudible] once in Angular 2, it’s taking the place of something I would normally attend a controller for or the template in Angular 1. Not always but often. Then a directive in Angular 2 is really just another flavor of a component.
So a directive in Angular 2, there’s two flavors the way that I think about it and I’m probably not using the official words here; I’ll lean back in the docs for it later but there’s structural layout directives which you can identify those because of the ones that always comes with the asterisk before them like ng-if or ng-for for example. Those are ones that are built in generally. You can actually make your own but they're built in generally and they actually modify the structure of the dom.
JOE:
When you say modify, the structure got to be clear about that. It’s not like ‘hey, we’re setting display: none’ or something like that. This is a significant modification. We’re adding those, removing those the way that ng-for and ng-if work. We’re pulling pieces out of dom; we’re sticking a bunch of pieces into the dom. We’re not just maybe modifying an attribute value.
JOHN:
Right, and those are structural or layout directives, whatever the official word is going to be there. Then there’s a – I can type a directive which is just regular directives. I like to think of it as being more like attribute directives for Angular 1 where you need to create something that’s going to enhance something out that’s already there to modify its behavior.
For example, I always like to use as a validation corrective; maybe you’ve got [inaudible] cost in validation and you wanted to show some stuff on the screen but it’s always going to modify an input or a button or something.
Those two types of directives – structural directives which we’re probably not going to write a lot of. Then there’s ones that you will write that are attribute based. The third type of thing, you're going to write components in Angular 2. To me, in my head, that’s how I separate them out; components are for my screens or subsets of screens like sub-views. Anything visual I’m adding, that’s mostly and HTML element, almost like an element directive in Angular 1. Then I’ve got regular directives which are more like attribute directives for which enhance something else for Agular 2. Then I’ve got the structural directives which quite frankly, I’m very rarely ever going to write my own ng for.
JOE:
Right. Okay, I could totally go on a rant about this because not necessarily of anything that any specific person did or team did that was a bad thing but because of the way that the names ended up working out which is partially not the fault of the Angular team.
JOHN:
Do tell.
JOE:
For those who don’t know the history – you John, you probably know a lot of this history – is way back in the day – in Angular 1 in fact, there were those three types of directives but they didn’t have a different name; they were just how you created a directive to determine it was one of those three types. The Angular team knew about this; they talked about this internally. So the ng-repeat and the ng-if directives – those were the structural type of directives. At the time, they like to call them template directives.
Then, there was the attribute directives that you're talking about. They called them decorator directives. Finally, we have the main one which is kind of – it could be a controller with a template but you turn it into a directive, some directive that has a view. Maybe a better example of that would be a button or like a date picker – something like that. That is a component directive. It’s some directive has a view and you almost always represent that with an element. You would almost never use an attribute unless maybe you're dealing with IE 8.
Those are the three types of directives and they have their names – components, decorators and I believe they call them templates which I thought was a silly name. I always call them structural.
JOHN:
I agree.
JOE:
I talked about this in my Plural sight course about the three different types of directives which I built quite a while ago. Then Angular 2 was still being developed; even two years ago, they're still working on prototype for Angular 2 so you knew they were going to have this kind of things.
They moved forward with this and then decorators became ES 7 thing.
JOHN:
Yup.
JOE:
So they had what they called annotations and the ES 7 committee adopted it but called it a decorator. So now they lost – they had the choice – do we want to overload the use of the word ‘decorator’ and make it – it’s an ES 7 thing and it’s also what we call a certain type of directive.
Again, if you have seen Angular 2, you use these annotations which are also ES 7 decorators in order to create these components or directives. Use the ‘at’ component and that is a decorator, an ES 7 decorator and it’s –. Again, annotation still applies because it’s a specific kind of decorator but anyway.
So you could have an ‘at’ – you can have a decorator whose name was ‘at decorator’ which would be really silly and everybody – and I would just give more fuel for Shai Reznik to do another ng-wat talk. [Laughter]
JOHN:
We don’t want to go there.
JOE:
So they drop that and then they used the word – they didn’t have a word. They could think of anything. So initially, what they had planned with Angular 2 was – directives – was going to be the parent class and component decorator, and structural or template or something like that was going to be the three different child classes. There was actually an inheritance hierarchy going on because they were reusing similar code. Well, decorator – they lost over decorator so now they have the directive as the parent but they have a component child, they have who-knows-what child and then template.
As I’ve talked about this in several talks in fact – I’ll link one of the talks that I gave. In fact, this is a talk that I gave for a Remote Conf – Chuck’s Remote Conf a while ago. I talked about this a little bit but we never build our own structural directives or these template – these structural type of things.
We didn’t do it in Angular 1; we really aren’t going to be doing it much in Angular 2. They didn’t necessarily need a name for it, the star ng-if, right? We don’t need it because people – developers are going to be writing stuff [inaudible] these, having a name for that kind of directive and talking about it a lot is really unimportant because it’s not a big priority. So they didn’t need a name for that; when they didn’t have a name for the second kind, they still could use component. So we have components but now they're just calling that second type which was directives or decorators, now just calling it directives.
Well, that’s fine if we think of – okay, we got components, [inaudible] creating components when it’s like a view and it’s an element, a custom element. Or I’m going to create a directive when it’s just an attribute that I’m throwing on a tag to give it more functionality but internally, directive is still the parent class of component. A component is just a specialized kind of directive.
So it’s a funny situation where the names are a little jumbled and I feel bad that we’re pointing at the fact that directive is the parent class. Really, people should just think of – there’s components in the directives and they're two little things or they're similar to each other but one is a custom element with a view and the other one’s a custom attribute with some functionality but not really a view and that’s the way that you should think about it. Templates – don’t worry about that; that’s in the framework. You don’t – it’s nothing you need to worry about. Don’t worry your pretty [crosstalk].
JOHN:
Yeah, the structural layout template ones. Yeah, the ones with the stars, you can pretty much just put aside for the most part. [Crosstalk] You’re not going to write those. You're going to use them, just not going to write them.
JOE:
Right. So understanding what their name is for the type of thing is really unimportant. We have these star things and we use them in our templates and that’s good enough. [Crosstalk]
JOHN:
Well if we get down to how you ask yourself a question to pick these – and I kind of agree with you here – the name’s a name, the name – who cares but when you're thinking about what you want, if you want something that is going to be an element versus an attribute, I think that helps you decide right there. Give me an element, I’d lean you towards component; give me an attribute, I’d lean you towards a directive – I’m talking in Angular 2.
Another question would be do you want it to have some kind of visual interface? Is there HTML associated with this? Is there a template? If there is and you're going to add a template like you're making your own date widget for example, that might lean you towards a component.
I just put a link here in the show notes of the directory factory – sorry, the directive factory interface up in the Angular API. If you look through there, you’ll notice there is no template property. There’s no template that you can specify for a straight up directive. But on a component, you can. So this is it’s just the way to think about – if you don’t want to worry about what’s what, I think a component – you can think of that like ‘I’m putting something on the screen that’s visual and it’s an element’. A directive in Angular 2 is more of just something that’s helping describe something else.
JOE:
Absolutely. That’s the way you really should be, thinking about all these sort of stuff. I went on this rant and talked about all the [inaudible] just for the kicks and giggles for the viewers to have something. [Chuckles] But it’s unimportant. Really, when you're learning Angular 2, it’s really – put all that aside, it’s more minutia that’s entertaining to listen to but not germane to learning Angular 2.
You really should – and we said this in Angular 1; I was very natural. If you wanted a directive that had a visual component, you created an element, you gave it a template. If you want a directive that you just stuck on as an attribute to an existing element and you created an attribute without a template, it’s very natural. I think people are going to find that’s extremely natural in Angular 2. I
create directives sometimes, I create components sometimes. They're two entirely different things and I don’t get confused in my head as to what’s what and how they work. It’s going to be very straight forward and that’s certainly what I found.
JOHN:
So Charles.
CHUCK:
Uh-hm?
JOHN:
Just because we’ve been ranting [laughter] and you're a little newer, self-admittedly, to some of the components and all that stuff, does that clarify for you the way that we’re classifying a component versus a directive in Angular 2?
CHUCK:
I believe so. For the most part, I get the history at least at a high level and some of the other things you’ve talked about. For the most part, the most useful bits for me are the parts where you're talking about where you have – for example, if you want it to be an element, using a component versus using a directive if you're going to make major modifications and things like that, just where the different functionality needs to live and how it all hangs together. It’s very helpful to visualize where I’m going to put what code and how it’s all going to work.
One thing I am curious bout though is that I’ve only seen Angular 2 code; I haven’t actually written any Angular 2 code, and it seems like a lot of it winds up in one component file. Does the directive live in there, too, or does that go in its own separate file?
JOHN:
We’re going into styling at that point and to me, those are separate.
CHUCK:
Okay.
JOHN:
Because if I define a directive, that directive may be used in a component but it may be used in other components, too.
CHUCK:
Right.
JOHN:
So I define my directives as their own thing and then you just – you can reference those directives from other components. So yeah, I would separate your directives from your components the same way we did in Angular 1.
JOE:
Let me see if I – I’m not sure that I totally understand your question, Chuck. In a component, when you're defining a component, you're defining a template, you often have the components class code alongside the template for [crosstalk]? Are you asking the same thing of directives or [crosstalk] would you put a directive and a component both on the same event? If I had a project that needed a directive and a component, would I put them both on the same file?
CHUCK:
That’s what I was driving at was both really. [Crosstalk] A lot of times, I see the in-line template, and a lot of people at Angular Remote Conf were – they were really excited that they had these inline templates and it makes a lot of sense if it’s a simple template. Why create an extra space if I can visually groc with the template is in one go. But I was wondering if you had a component and a directive that the component is actually using the directive in some way; would you put them both on the same file and then [crosstalk] no because directives could be used to cross multiple components. What that means is that then I can have that shared functionality in its own place and I can – it denotes that it’s a separate piece that may connect to the other pieces in my application.
JOE:
Yeah, there’s probably a couple of reasons there, why you should separate them out. First off, think back to Angular 1; if I had a controller with a template and there’s a directive that I happen to use in that controller and a template, I certainly could throw the directive inside the same file. But it becomes somewhat unnatural; we tend to think we quickly got to a place where every object had its own file even though the stupid Angular seed which I will never, in my life, wants to say there was anything great about it. [Laughter] I hated that.
JOHN:
– the Yeoman generator?
JOE:
No. I’m talking angular-seed.
JOHN:
Oh, yeah.
JOE:
The earlier versions – later versions may have changed this but certainly the earlier versions, they had a file called directives, put all your directives in. It’s kind of bad pattern.
Anyway, we quickly got to a place where every object has its own file. So that’s one reason obviously to just stick – if you have a component that needs a directive, stick the directive on its own file just because it’s far more natural for each thing, each piece of your application to have its own file.
Now, there’s another reason for that as well. Using modules, which is hoe Angular works – Angular 2 works – it uses the ES 6 module system. In order to consume or utilize something, you have to not only –. See in Angular 1, when you build a component or a controller or a directive, you registered it internally in Angular by calling the Angular – module.controller function or the module.directive function. I actually registered it internally in Angular 1 internal registry which seemed like a really nice thing but it was actually a really bad thing for a lot of different reasons too many to go into.
In Angular 2, there’s no internal registry. There’s no single Angular 2 registry that says ‘I know about all of the components in your application’. Instead, you say ‘hey, this component needs this directive’ so at the top, you bring it in by requiring it using the module system, then now it’s available. It’s just there in the file, basically now local to be used but that directive has to be exposed by the other file.
In the other case, if you ever want to reuse it, you’d have to expose both of them. That would be kind of weird because we’re more used to – this is only kind of true because with Angular 2, the libraries themselves, one single file might expose a lot of things but that’s because they combine it all together. But for our code, we should think of each file contains one thing. So you wouldn’t want to ‘If I want to reuse that directive, I have to bring in the file for the component but I’m only grabbing the directive out of it’. It just look really weird. If the directive was named ‘date picker’ but I’m bringing in the user panel file to get the date picker, that’d be really odd.
CHUCK:
Yeah, that makes sense.
JOE:
So there’s a couple of good reasons why you should keep your – each piece of directives and components in their own file. I think what is another interesting question is the whole in-line templates versus separate templates.
JOHN:
Oh yeah.
JOE:
I think that’s really interesting because now that we have ES 6 and Angular 2 is definitely encouraging people to take advantage of it because of the module system and multi-line template strings which now let us says ‘hey, I could put a template inside the same file but it’s no longer limited to have to do a whole bunch of string appending or putting it all in one line’ which obviously gets unmanageable after a template is longer than forty characters.
We have multi-line stings now so that we can have this nice HTML string, and there’s plenty of editors that are letting us treat this one string inside of a JavaScript file as HTML and get all our Zencoding and syntax coloring for HTML so we can – [crosstalk].
JOHN:
What editors are those, Joe? What editors will help you do that?
JOE:
Well, a web [inaudible] and Sublime Text will and Visual Studio Code will.
JOHN:
Code does not yet but it will, yes.
JOE:
Okay.
JOHN:
That’s one of the wish list items I have on my list. [Crosstalk] You're talking specifically about having an HTML file – not HTML file, HTML embedded inside of the template strings inside of a TypeScript file. It doesn’t give you that yet but it’s my dying wish right now. [Chuckles]
CHUCK:
Yeah, and I believe that there are plugins for Vim and Emacs that will allow you to have, in Emacs, at least multi-major modes. Then you can have an HTML major mode for that string and the TypeScript major mode for the rest of the file.
JOHN:
That’s not – let’s be clear, this isn’t an Angular 2 thing even. React is in this kind of stuff too, so I think Edgar’s – if they don’t do it already, I think you're going to see all the major editors do this soon.
JOE:
Right.
CHUCK:
Well, you see a lot of these editors do the same thing for JavaScript inside of HTML. It’s effectively the same thing; you're just turning on different syntax highlighting and other nice code autocomplete, et cetera, features for the majority of the file and then the rest9 of the file that needs a different syntax and other nice tools on it.
JOHN:
Let me be clear about my stance today; if we don’t have that in the editor, if we didn’t have the full HTML editing experience and autocomplete [inaudible] and syntax coloring and all that, inside a TypeScript file or JavaScript file, I would not be doing in my HTML at all in my files. Today, VS Code doesn’t have it and I’m using that yet so I’m not doing that because it bothers me to have my HTML in there and I can’t tell if there’s a syntax there.
I can’t visually separate where the binding is versus the property versus the element but once that comes in – let’s assume it’s all there and all the editors because I know WebChurn does that, too, but if we have that, where do you draw the line, Joe, and how do you fell, Charles, about if I have a template and I want to do in-line inside of TypeScript and I have styles under the in-line inside my TypeScript or JavaScript, where do you draw the line and keep it in that file or move to an HTML file? Do you do a number of lines of code? Do you always put it in line? What do you guys think?
CHUCK:
I have such a woo answer on this.
JOHN:
A woo woo?
CHUCK:
I know people really like having those rules. It’s ‘well, if you have 20 lines of code then you need to move it out’. But my thing is if I can’t look at it and immediately understand it, it’s got to go in its own file. It’s got to go somewhere and got to be broken up so that I can understand it. For the inline templates, there’s got to be something that’s going to fit in however many lines of code I’ve got in my text editor. From there, it’s got to basically work out so that if there’s a lot of ‘if this, then that’ or stuff like that where I’m looking at it and I’m really trying to figure it out, the rest of the component’s going to feel like noise to me so I’m going to pull it out.
I’m also going to be looking at if there’s any way I can do partial templates or things like that that are going to make it so that all the little pieces aren’t quite so gross to deal with.
JOHN:
You indirectly hit the nail on the head, Charles, that people use this [inaudible] a lot and that’s if you're component – I’ve heard this a lot – if you're component has so much HTML that it’s pushing everything else off the screen, whatever size of screen you use, then you probably need to think about breaking that component up into other components.
I get that point; I’m not sure I 100% agree yet. I’ve written of Angular 2 apps, you have to really know how I feel about that.
CHUCK:
I don’t know if that’s what I’m saying. I don’t mind if I have to scroll in order to see the entire component, but the template – because the template is something different from the component. The component is mostly behavior and the template itself is mostly just HTML; it’s markup, it’s static. It’s not doing anything interesting. So I want to be able to just see it as part of my component and just look at it and know what it is and know what it does.
JOHN:
That’s more – for me, it’s distraction. Can I open this file and understand what’s there? Whatever the file may be, if the HTML’s getting in the way of me understanding of what the component does then I want it in its own file and vice versa.
JOE:
I think this is a very interesting thing and there’s a couple of reasons. React came out a while ago and one of the things React did that was almost shaking the foundations was to say ‘we’re going to put our HTML right in there with our JavaScript’.
JOHN:
Right.
JOE:
So first, people are like ‘what?’ and then all of a sudden they're just like ‘oh, my gosh; this is so great.’ The React actually says this – they say,” We should separate concerns but we got it wrong when we said that the HTML was this entirely separate concern form the code that drives the HTML so they should be together. I don’t disagree with that point.
What I like about Angular 2 is that it gives you the option to choose whichever works for you. So as much as I would say lines of – I could come up with some guidelines for lines of code or pushing out the screen or whatever, I also think that there’s a great opportunity there to say, “This works better for us.”
Maybe we do have a designer that wants to be able to go into our HTML and mess around with stuff in which case, let’s put it in a separate file. Maybe we don’t; maybe we get our HTML from some odd place so we do want it to be separate, maybe we don’t – we have those options. I think this is – it’s a very cool thing with Angular 2 that you have a choice.
Now personally, what I hope we’ll see is that as people go in and start building a component, if they keep their HTML in with the component itself and then they have this idea, either ‘oh, there’s so much HTML that’s pushing it off the screen’ or ‘there’s too many liens of code; I don’t like it if there’s more than X number of lines of code’. What will happen is instead of people ‘oh, I’m going to take the template out and throw it in its own file’, instead people start writing smaller components. I think that’d be awesome.
CHUCK:
Yeah.
JOHN:
I like the idea of smaller components. Frankly, I don’t think it matters if you put your template in-line or out-line; I guess another file. Consistency’s a big thing; have a plan. It’s the same way like I do with Angular 1 Style Guide. Whatever you do, I think you should just have a plan. How do you decide? Maybe for one team, it is lines of code and that’s important to them and that’s how you decide. Maybe for other teams, it’s not lines of code like Charles was saying, maybe it’s something different.
Whatever that is, you should know how to find your code, you should know how to edit it, and when you open your file, it shouldn’t be a big pile of mess that you have to sort through to figure out where’s that and what is this thing doing again? So as long as you can open your file up and you can understand what’s in there, I don’t really think it matters.
CHUCK:
Yup. My thing is that I don’t want people to go ‘well, I’m going to follow the John Papa rule for this’ without understanding that this may work differently for them. So definitely, try a couple of different styles and see what really makes a difference.
I don’t think we’re going to have a really good grasp on what the best way to do this is until we’ve actually been building with Angular 2 for a while.
JOHN:
To be clear, until we have all editors doing – we’re assuming editors will all do these.
CHUCK:
Yes.
JOHN:
In that case, this is relevant if not all editors do this then right now, quite frankly, I’m just taking the HTML sticking on its own file so I can actually get all my editor features.
CHUCK:
Yeah, the thing is I’d be really frustrated if I had this component that I knew was critical to my app. Ultimately, I went to look at the template file and it was span, enter some dynamic text, close span.
JOE:
Right. There also is varying levels of support for the editors. For example, I use a lot of Sublime. It does syntax [inaudible] I believe but it doesn’t handle – I can’t use – I can’t find a plugin for Zencoding so I can’t type in an open brack, like just a word and hit tab and have it turn it into an element and it’ll create the [inaudible] for which I love that; I’m doing that in WebStorm. But it always seems like WebStorm’s ahead of everybody’s curve.
CHUCK:
There’s a plugin for that for Emacs if you want to come to the light side.
JOE:
[Chuckles] But will I do it? Is there a plugin for that, for Emacs? Inside of an in-line HTML/ES 6 string.
CHUCK:
Emacs Lisps baby, Emacs Lisp. You can make it do it yourself.
JOHN:
Oh my.
JOE:
Yeah, I did not want to program my editor. I want to download some [laughter]. Now that I wouldn’t find it fun but I’ve got something else I’ve already found fun and I want to build that and not go out for another fun project.
CHUCK:
Yeah.
JOHN:
I think for people getting started by building these components and choosing their editors, this stuff is all going to settle down. But the component stuff, something you pointed out, Joe, I think is important is if you're embedding your HTML like in React, a lot of the way React works is you create a function in JavaScript that then returns this HTML or can modify the HTML or does something with it.
The way that Angular 2 does it, in my way – the way I look at it is it’s a lot easier in Angular 2 to take this HTML/JavaScript convergence. And even though it may be in the same file, the HTML’s actually still logically separated from the JavaScript. There’s no – it’s not what this function [crosstalk].
JOE:
Yeah, which is interesting. It’s very different from React. React is mixed right into your logic.
JOHN:
Exactly. They're still both in the same file but it’s the way they're in that file. In Angular to me, they're still separate; it just happens to be in two different places in the same file.
JOE:
Yup. So it is an interesting bridge.
CHUCK:
Yup.
JOE:
Internet flavor, you might say.
JOHN:
I think people are going to build a lot of components, I really do. I think the way controllers work and the way a lot of directives work, I think that things that were controllers and were elements and directives are all going to converge from Angular 1 into these components in Angular 2. I think we’re going to see that be the hot thing; how do you build these things?
CHUCK:
Let me toss this one out there – everything I see in Angular 2 is components. Does it still have controllers?
JOE:
Nope.
JOHN:
Uh-uh.
JOE:
Just components. Component – it turns all the way down, components all the way down.
CHUCK:
Okay.
JOHN:
Although you could create a component called controller.
JOE:
Yes.
CHUCK:
The Joe controller?
JOHN:
I think somebody like Igor or the Angular team might come and tear your house and beat you up if you do that, Joe. [Chuckles]
CHUCK:
If I get Igor to come to my house, I’m definitely doing it.
JOE:
Angular 2 probably throws an error if you try to create a component named controller. [Laughter] It’s going to be hilarious.
CHUCK:
Yeah, or just mix something in Angular so that it does.
JOHN:
Yeah. It’s interesting because components are neat. I ran into this situation early on with my Angular 2 exploration and that’s I created a component, then I immediately wanted that component to be something that had inputs and outputs to coin that now. There are properties and events before.
Basically, I wanted to have a component like hero details on the Tour of Heroes. That component is – I chose details about our hero named Joe Eames but to show details about a hero, you need to know who the hero is. So something has to tell it ‘give me the hero ID’. So I immediately said, “Okay, let’s create an input of the ID,” which is like thinking about an isolated scope.
You might create scopes and property in our directive in Angular 1 and say ‘somebody tell me the ID and I’ll figure out the rest to show the hero. Well, what if I also want to use that thing in a route such that I want to be able to route to a sub-route with a heroes/14, and that 14 means you don’t go to the heroes list but go to the details thing and show me hero ID 14. Now, I’m not binding that 14 like I did before with an [inaudible] but I’m doing it through a route [inaudible].
What’s neat is you can actually define a component and the tour of heroes does this in a yet unpublished part which would be coming out very soon where it shows you how you create a component that accepts your inputs and outputs or it can be used from a router which makes it neat because that component can actually work in either place.
I think it’s cool because – what I was getting at is that I think in Angular 2, things are more flexible than they were before. There’s less concepts, yes, but it doesn’t mean you're locked into something. Components actually can be used in multiple ways which is wicked cool.
CHUCK:
That’s the thing that I’m seeing with it. It has the best of both worlds in the sense that if you look at a component or look at a whole bunch of different components, they all kind of structure up those same way you approach them generally in the same way, but there’s so much room to move in there that you get your critical parts all pointed in there and hooked up. You can do pretty much anything you want from there.
So you have all kinds of flexibility inside of the framework and you just do it in a way that the component knows that it’s there and knows that it works.
JOE:
I think we’re probably reaching the end of our show. I know we have some hard stops but what I think has been very interesting about this because when we started and decided this is the topic we’re going to talk about, I didn’t feel like there was going to be much material but [inaudible]; we talked about a lot of stuff.
JOHN:
Yeah, there’s a lot to know, you're getting into components – are you a component, are you a directive, are you a structural directive, where the heck did these things come from and how do they relate to what we did in Angular 1? There’s a lot [crosstalk].
JOE:
My code has identity crisis. [Chuckles]
JOHN:
Just don’t call it controller.
CHUCK:
The other thing is that I feel like angular 2 gives us some lines to color in but it’s nice to get a little bit of shading and shape to the direction you want to go with it.
JOHN:
Yes.
JOE:
Okay.
CHUCK:
Alright, well let’s go ahead and do some picks. Joe, do you have some picks for us?
JOE:
Yeah. I put in a link in the show notes of the talk that I gave at your [crosstalk] conference.
CHUCK:
Angular Remote Conf.
JOE:
Angular Remote Conf, yes. I want to pick that talk just because it’s very germane to the subject because it’s about Angular 1 directives and Angular 2 directives. A little bit – I talked about this subject a lot about Angular 1 and Angular 2 directives and the relationships between them. But I think most of that talk was actually just about the basics of Angular 1 directives that I just want to pick that talk. I think it’s a good pick and very appropriate to this subject.
The other thing I want to pick – this is going to be crazy – Seth MacFarlane. Do you guys know what Seth MacFarlane does?
JOHN:
Yes sir.
JOE:
Okay. Check [inaudible] of what Seth MacFarlane does.
CHUCK:
I’ve heard the name so [crosstalk].
JOE:
Creator of the Family Guy and he does a lot of voices like he voiced Brian the dog on Family Guy. He’s – at movies, he directed or wrote in the start of the movie A Thousand and One Ways to Die in the West or whatever it’s called.
Seth MacFarlane has several albums – they're on Spotify; I don’t know. I’m sure you could buy the CDs as well. He is an unbelievably amazing singer. His voice is smooth as butter which if you’ve heard him voice the actors on Family Guy – dude’s voicing on Family Guy. It’s not necessarily surprising. He has actually sing a little bit but he has this crooning voice that is like right out of the Rat Pack or something, just amazing. He has this Christmas album I’ve been listening to. He has other albums. Unbelievable; I just can’t believe how talented that guy is even though I don’t always like Family Guy although a lot of them makes me laugh. My wife does not like me watching it. [Chuckles] That’s going to be my other pick. It’s Seth MacFarlane as a singer; not necessarily as a director but as a singer.
CHUCK:
Alright. John, what are your picks?
JOHN:
I’ve got a couple, too. We talked about this so I’m going to go ahead and put a link into our show notes. I think I just did that.
In VS Code, there is a user voice site where you can ask for new features and vote on them. One of those I just found was HTML editing within a JavaScript/TypeScript code for template strings. [Crosstalk]
JOE:
Oh my gosh. That’s so awesome. [Inaudible] 50 ridiculous requests.
JOHN:
Yes. You can vote – you can make as many as you like but you can only vote up to ten votes on things but please go vote this up. That’s be awesome. Let’s crowd-source this and get this high on their list to do things.
The great thing about VS Code, too, is that they just released their – part of my picks here is the VS Code just released their beta, and as part of their beta, they released the ability to write extensions for it.
CHUCK:
Nice.
JOHN:
One of the extensions that was written for it – if I can go find the page really quick – some guy named John Papa wrote an extension called – what did I call the darn thing? Oh man, I got to start drinking. [Laughter] What is this thing called? Oh my gosh, Angular 2 and Angular 1 snippets extension. So if you're creating Angular 2 code, you can download the – you can [inaudible] the snippet for VS Code for Angular 2 snippets and it actually lets you type in ‘what are the component syntax?’ It’ll fill it out for you and lead you the way to get you there. So that’s my two picks for today.
[Crosstalk]
I do and I’m going to find the second one. I also have a third pick which is there is this crazy conference by this bald guy named Charles Max Wood called Angular/JavaScript Remote Conf thing. [Laughter]
CHUCK:
That’s the official name. I’m changing the website and the domain. [Laughter]
JOHN:
It’s in January, right Joe or Charles?
CHUCK:
Right Joe? [Laughter] Yes it’s in January the 14th through the 16th.
JOHN:
You think I would be drinking the way I’ talking right now. During that I’m also speaking there I think on a Friday. I was just told so I’ll be speaking there about Angular 2. It should be lots of fun and please come join us.
CHUCK:
Awesome. Yeah, I’m excited.
JOE:
Chuck, this is something you’ll find interesting. I was just looking through those suggestions; there is a suggestion for Visual Studio Code for Vim style key bindings. FYI, the one for – you linked, John, the HTML editing within JavaScript had 50 votes. The Vim style key bindings has almost 5,000.
JOHN:
Yeah, that one’s been out for a while. I know this guy from my work uses Vim and he’s like a [inaudible]. The guy can type with his toes and moves faster than me.
People who are into Vim, I totally get it. They can just fly so I’m interested in checking that out.
CHUCK:
Yeah, I’ve seen the same thing between Vim and Emacs. You just get used to – since you don’t have to move off to the mouse which I’m not sure if you can substantiate that with any real science, I see that that moves things along. The other thing is that they're both so malleable that you can basically make them do whatever it is you need to do quickly and you can really get a lot of power out of those older text editors.
Anyway, that’s why I use Emacs because I can customize it to be exactly what I want and then I just fly through my code.
I’ve got a couple of picks here. The first one is I got a text message from my dad about five minutes ago. I’ve been following that because he had open heart surgery yesterday and he just moved out of the ICU. So I’m just picking good news because I’m really happy about that. I was a little worried about him and he was worried that he wasn’t going to get out of the ICU when they told him which meant that there was probably a problem so I’m super happy about that.
I was also going to shout-out that the videos from Angular Remote Conf are now public on YouTube. I’ll put a link to the playlist in the show notes. If you want to go watch those, you can.
I was also going to shout-out about JS Remote Conf. Definitely get tickets. If you have a company or users group that wants to come as a viewing party or as a group of employees across the world, wherever, we do have group tickets so you're welcome to sign up for those as well.
I’m also taking sponsorships for those conferences. So if you're looking to sponsor an event that reaches a global audience then check that out.
Anyway, those are my picks. I guess we’ll go ahead and wrap up.
JOE:
Chuck, can I interject one thing as well?
CHUCK:
Yeah.
JOE:
If you're a company who is in the mood for sponsoring conferences, also ng-conf is now available to sponsor – ng-conf 2016 is now available to sponsor as well. You just go to the ng website to figure that out.
CHUCK:
Yup. Oh, that was such a good event last year.
JOE:
It’s going to be even better an extra day. Woohoo!
CHUCK:
Woohoo!
JOHN:
I can’t wait.
JOE:
Yup. There will be – I haven’t even asked Chuck for permission for this but I don’t even care. There will be another, yet again, live episode of Adventures in Angular at ng-conf 2016.
CHUCK:
I’ll have to talk to the panel about – no that’s fine. [Laughter] That sounds great. I will be there so if it’s just Joe and I – but I’m sure the other panelists are going to be there, too.
JOE:
Well, fairly unlikely that John will get us talk-approved. [Laughter]
CHUCK:
You had the inside track on that, huh?
JOE:
Uh-hm.
JOHN:
Yeah, I’m really looking forward to it. It’s actually one off my favorite conference now that I go to. I’m not just saying that; it’s a really, really well-done conference.
CHUCK:
Yeah, it is. They do things that I really don’t see at other conferences that just make it fun and unique as much as anything else. It’s not just the community, though that kind of is what makes the conference such a great conference but all of the other events around the conference. So there’s Ski day and there’s the Starcraft tournament and things like that. They really go out of their way and do some really wild stuff that it’s just a lot of fun to be at. It gives you something to talk about with the other coders that are there that isn’t necessarily just Angular or just Misko and Brad and Igor told us about the day before.
JOE:
Right.
CHUCK:
So yeah, I will be there. Sounds like John will be there. Joe will be there. So if you want to be there then – I don’t know if the tickets are sold out yet but there’s probably [crosstalk].
JOE:
Yeah, there might be a few more that go up on sale but pretty much the only chance to get in now is if your company’s a sponsor.
CHUCK:
Okay.
JOE:
Tickets have been sold out for the most part for a while.
CHUCK:
Okay. So that’s your way in. If you want to go, sponsor the conference.
Alright, we’ll go ahead and wrap up the show.
[Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net]
[Bandwidth for this segment is provided by Cache Fly, the world’s fastest CDN. Deliver your content fast with Cache Fly. Visit cachefly.com to learn more.]
[Do you wanna have conversations with the Adventures in Angular crew and their guests? Do you want to support the show? Now you can. Go to adventuresinangular.com/forum and sign up today!]