[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 73 of the Adventures in Angular show. This week on our panel we have Ward Bell.
WARD:
Hello everyone.
CHUCK:
Lukas Reubbelke.
LUKAS:
Holler!
CHUCK:
John Papa.
JOHN:
May the force be with you.
WARD:
Oh no, you didn’t.
CHUCK:
Hey, I’m with John on this one. I’m Charles Max Wood from Devchat.tv. Quick reminder, go check out jsremoteconf.com. The conference is January 14th or 16th. We are going to be talking a little bit about architecture with Angular 2 now that it’s out in beta. I think Ward is going to explain it a little better than I can of what we’re after here.
WARD:
Yeah. We’re all pretty excited about the beta release which was yesterday relative to when we’re recording.
CHUCK:
Woohoo!
WARD:
Woohoo! Beta means, by the way, that we should expect fewer breaking changes than last year. [Laughter] I think that’s how that works.
JOHN:
So we have the beta 42 yet?
WARD:
We are in beta zero as we speak but I heard the team talking very seriously about controlling the breaking changes. It’s not that it can’t happen but you have to run a gauntlet now to get a breaking change and if it hasn’t been pre-approved. I’m feeling pretty confident that we have crossed an important divide and the product will expand, it will improve but it will not break on you.
With that said, our wish as a podcast is over the next weeks and months, really go into how Angular 2 is put together. We’ll talk about other things of course along the way but I have some real substantive shows about what Angular 2 is and how it works and ask challenging questions.
We thought we’d open with a discussion of the most important architectural aspects of Angular 2. There’s a page on the developer guide that’s dedicated to that; we’ll put that link in our show notes. It begins by identifying eight main building blocks. We thought we would try and take a look at those, see if they make sense to us, chat and challenge them and so forth. The first one on that list is the notion of a module. If you’ve looked at any of the samples, you’ll see – the TypeScript samples – you’ll see they really emphasize that Angular applications are modular, they're build up out of modules – the small modules that do one thing; modules usually translates to a file with one class in it. You’ll see, if you look behind-the-scenes, a reliance on some kind of a module loader to help you dynamically assemble the application on the fly as you're going.
So if you will look at your index.html for example, it has a bunch of scripts at the top and then one system import – that’s the module loader it work – loading the top level component that sits at the root of all things. After that, you don’t see more on your index.html because some module loader – in this case, SystemJS – is busily loading files as you need them and resolving their interdependencies as you need them to. And that notion is [crosstalk].
JOHN:
Ward.
WARD:
Yeah.
JOHN:
Can I – I love where we’re going in this but can I step back for this quick sec.
WARD:
Sure.
JOHN:
I got to ask this literally about 20 times in the last days since the beta was released. It’s for Twitter and other rooms and that’s – okay, it’s out. People start feeling compelled now to figure out what can I learn and where should I start? They started throwing out all these terms, all these features like hooks for lifecycles, the inputs, the outputs, interfaces. I think you're trying to grasp of the five million things you could learn in Angular, where should I start [inaudible]? I think what we’re settling in on this episode is – what we’re suggesting is start with the architecture. Start with ‘here are the most important things you need to know about Angular 2 when you start coding’. Is that right?
WARD:
I think so. Of course, the first thing you want to do is a Hello World just to know that the thing can stand up and breathe and it’s not going to kill you to do it. You certainly want to take this Tour of Heroes thing that I think you know something about. But when you're really trying to learn it, that’s where I think people should start. They should start with getting an architectural overview so that we know where the big pieces are. [Crosstalk]
JOHN:
It’s hard to dive deep on everything.
WARD:
Yeah.
JOHN:
You just want to get an idea of ‘what does the playing field look like’? [Inaudible] of course. I used to golf a lot; I don’t anymore but when you go to a golf course, you get an idea of what does the hole look like before you go play it.
WARD:
Yeah.
JOHN: and I think that’s what this is about. What is my experience going to be about?
CHUCK:
Yeah, what I’m seeing here with this is that essentially, this document tells me where I’m going to be putting all off the bits and pieces of my application. Some of the things are going to wind up in modules, and within the modules, you have components. Some of the stuff is going to wind up in the component, some of it’s going to be in the service, some of it’s going to be in the template so it’s okay. Here’s how you think about where you're going to stick this stuff so once I know the shape of the different blocks that I can build things with, then I can go back and I can actually put together an application that makes sense and use these tools properly so that they all talk to each other in the way that Angular expects them to.
WARD:
That sounds right to me, Chuck.
JOHN:
That’s a good way to look at it. I’m curious since Ward was the main driver of this document and I think it’s fantastic actually. But I’m curious to see if – I don’t know if you guys have seen it before – what is your impression when you look at this?
CHUCK:
I hadn’t seen it before today. It’s interesting; having built some Angular 1 apps, looking at this and seeing a little bit of where things are different and a lot of where the things are the same. For example, directives – they’ve changed but the concept is basically the same. Databinding – it works a little bit differently but a lot of the concepts are the same. The component and the template are – there are little bit different approach to some of the things that I’ve done. Dependency injection is done with the injector and that works differently, but dependency injection is the same principle and it works mostly the same way.
Looking at this, if you’re familiar with Angular 1, you should be able to browse through it. I had to read the module section twice to really feel like I understood it but the rest of it was pretty straightforward.
WARD:
That’s good. I had the same sense that you can almost visually see here the alignment with what you know with Angular 1, what template – oh yeah, we used to have a view, we used to have HTML component. We used to have a thing called a controller – that sounds familiar. I think it’s right.
CHUCK:
I do see that one thing that I didn’t use a lot of, or if I did, it was just the way that it was presented to me is the module. The module seems to be a little bit more of a major departure from the way I usually did things. Having written a lot of code in a few languages like Ruby – for example, I’ve done quite a bit of Ruby – it is nice to have that container where everything else lives and be able to move it around and think of it as one piece.
WARD:
That’s really an interesting point and I think – Lukas, in the pre-show you were talking about this a little bit, too. I should emphasize that this particular document is appearing within the TypeScript language track. There are other language tracks like those people who are interested in just straight up JavaScript, or there are people who are interested in Dart; those are the two other language tracks. In the JavaScript language track which were just being developed from the documentation perspective.
We make a point which – it’s also true for TypeScript which is you actually don’t have to use modules if you don’t want to. Yeah, I know. Shocking. [Chuckles] It’s just shocking. Modules are so natural within the TypeScript and ES6 land that I’ve almost forgotten that you don’t have to use them. Certainly, in most of the examples, we do it and then we encourage people to do it but you don’t have to do it. In fact, you can program with IIFEs – immediately invoked [crosstalk].
CHUCK:
Function expression.
WARD:
Function expression, thank you. You absolutely can do that. You can just play your scripts in here like you did in Angular 1; you can create a name space for yourself, call [inaudible] app and put all of your application pieces on to that name space. There doesn’t have to be a module in sight; you don’t have to use import/export – you don’t have to do that.
JOHN:
This is really interesting, Ward, because when you first showed me this page, modules weren’t part of your thoughts, were they?
WARD:
That’s right; they were not part of this page originally.
CHUCK:
Oh wow.
JOHN:
And it – yeah, that’s the first thing. So when I looked it over, Ward gave me a change to [inaudible] my feedback. Quite honestly, I thought it was pretty darn awesome right from the get-go and everything in there was great but we have a tendency when we review things to think about ‘let’s just review what’s there’. But the one thing that stood out to me was when I’m learning Angular, one thing that’s always in my way in some way – not just Angular but Aurelia or React or anything new – is modules. We’re all heading there and while modules aren’t an Angular thing, if you don’t have a grasp of them, I feel like you're hurting yourself. I think that’s one of the reason I’m happy it’s in this.
WARD:
Yeah, I think you should do it but you don’t have to do it, and even if you decide you’d never want to use modules, it’s probably a good idea to at least understand it because you're going to learn from other people’s examples and they're going to use modules.
CHUCK:
Well, let me tell you a little story. When I was learning JavaScript, I was basically learning web development at the same time, so what we had at the time was Prototype – I think it’s what it was called before jQuery. Then jQuery came along and that was really nice so then most of my JavaScript was really bad jQuery. I call it spaghetti jQuery. So then things moved on a little bit further and I got to know another nice way of organizing my code called Backbone. I did quite a bit of Backbone and I really liked backbone because it gave a little bit more organization around my code, and at the same time I was using Rails and it gives you a whole lot more convention around the way that you use your code or write your code.
So when I discovered Angular, it gave me a little bit more nuance setup for the way that I wrote my jQuery essentially. The jQuery stuff was partially built into Angular which was nice so I didn’t have to think about it, I could just put a directive around something and it worked. So I would mostly use Angular to just enhance my HTML and make it do things that were a little bit harder to do without some plugin and a bit of know-how to glue everything together in jQuery.
WARD:
Uh-hm.
CHUCK:
Now, when I’m getting into Angular 2, all of a sudden, I have all these tools that I’m used to and another language that give me a lot more functionality and a lot more of the structure that I’m used to in these other places. It’s not that they didn’t exist before in JavaScript, it was just that having come up through Prototype and then jQuery and then Backbone, then finally into some medium version of Angular integration into my pages, I just never use them because my path never progressed at that point and I would have to go out of my way to learn RequireJS or something else in order to do that; I know a whole bunch of people who were in that boat.
So by having this first-class citizen in the languages we’re using now with typescript and ES6, you have a lot more people that are looking at it and not really completely understanding where it fits in because they're thinking of JavaScript and they're thinking of some of the other coding they do, they’ve kind of disassociated some of that in their head. So coming back to this and saying ‘hey look, this is real programming with actual, awesome primitives and ways of thinking about these problems in JavaScript’ is novel. I think it’s going to take some people a little bit off work to really get to the point where they're using this naturally in their code.
WARD:
That’s such a good point. I should really make it clear – Angular 2 doesn’t have its own module system; it’s just piggybacking on the stuff that we’ve learned in ES6 or ES 2015 or whatever you want to call it. This is a recommended way to roll; it’s a really easy way to roll in TypeScript but if this was standing in your way between you saying ‘I think I want to learn – I think I want to use Angular 2 but I just don’t know if I can take this on or not’, you can put the – kick the modules to the curb until you're ready.
CHUCK:
Yup.
WARD:
I’m glad we were able to get that point across. We actually have code examples of it they happen to be on the JavaScript side but they're there. Maybe we’ll, in the future show, really be able to walk that dog.
JOHN:
I think that’s important; we’ve got modules in Angular 1 – why do they exist? My view on that is we needed a way in Angular 1 to organize all of our stuff into containers or Tupperware containers as Dan Wahlin, our good friend, says. We had to have a way to put things together and associate them; now, we don’t necessarily need those because we can just use basic ES6 style modules to do that.
WARD:
But if you decide to go somewhere in between, there’s a pattern you can follow and it’ll work, and it’ll work fine because we’re doing it. We happen to be doing it in the JavaScript track, not in the TypeScript track because TypeScript just makes it so easy to use modules that why wouldn’t you use it if it was easy, but I completely understand that perspective and it shouldn’t get in your way.
The module system shouldn’t get in the way of your enjoyment of Angular 2.
CHUCK:
Yup. Let’s go ahead and – unless there’s something else that we feel like we need to cover with modules, let’s go ahead and talk about some of these other bits. We had an episode – I think it was last week – where we talked about components.
JOHN:
Let’s call out all eight of these things are really quick, just list them out really quickly then we can talk with the ones that maybe Lukas feels more attention.
CHUCK:
Yeah. So I’m looking at the list. We’ve got modules and we’ve talked a lot about that. Components, which Ward pointed out, have replaced controllers to a certain degree and we can dig in to what that is here in a minute because I think it’s an important distinction to make. Templates, metadata, databinding, service, directive and dependency injection. I know where my questions mostly are going to be at but I think we should just work our way down the list and at least give people an idea of what they're dealing with. And like I said, we did do an episode on components and directives.
WARD:
So we don’t have to cover that in depth.
CHUCK:
Right.
WARD:
Let’s give an intuition about each of these, too.
CHUCK:
Yeah.
WARD:
Okay. So we talked about module; component – that’s a controller. That’s something that controls whatever you're displaying on the screen that takes use input. It’s programming, it doesn’t – itself have any direct awareness of what the visuals are, what they surface is that the user’s interacting with – it’s programming. It’s programming to support a view.
CHUCK:
Yup.
WARD:
Template is the view itself; that’s where you put – lay down the HTML. That’s where you make it look good. That’s the sexy part. That’s where Lukas is because he’s so sexy. [Laughter]
LUKAS:
Aww!
WARD:
Aww! He’s hot. That’s where you see what you see. And you know what, this is an opportunity for the designer to do what the designer can do without having too much awareness of the application underneath. Obviously, you got to talk to a developer, you have to coordinate but they can be – they don’t have to step on each other’s toes. So this is good in classic pattern language. This is good view controller separation.
CHUCK:
Yeah. I do want to throw in here though – and I guess we’ll get to the metadata but the metadata on the stuff makes it, in my opinion, a lot cleaner and easier to separate these concerns.
WARD:
Exactly, because you got – without metadata, you just got a class that’s sitting out there in space. It doesn’t know anything; it’s just got some properties and stuff like that. You know it’s supposed to drive a view but it doesn’t know anything. [Crosstalk]
JOHN:
They saw the problem that we had in Angular 1, too. I keep going back to Angular 1 but we didn’t have metadata like this but it’s not like these are new things. All the metadata in Angular 2 that’s solving is – this component or this controller with Angular 1 has some HTML – where is that? What’s the name of the selector this thing’s going to have? So it’s just associating things that we had in Angular 1 and providing a much more structured, clean way to get there.
WARD:
Exactly.
CHUCK:
This is the real power – in my opinion, this is the thing that I like is that my template now just has – the example here has a hero list selector. I just put a hero list tag in there and I might have to put some other attributes on there, but for the most part, I just put the hero list tag in there. I don’t have to tell it ng-controller blah, blah, blah and here’s all the other stuff that you need to know because the component manages all that stuff. So it knows to go in there and do its job and put the template in place.
WARD:
Exactly. Picking up on your idea, I’ve written this hero list component – hero list controller, in fact [inaudible] but it says I don’t know anything about the HTML. I don’t know what to do with this. I know that it’s going to – I know this, I’m going to give it a list of heroes. I hope it knows what to do. That’s the way that you want to write the component. As an author of the component, you're trying to make sure that you can go out there and grab some heroes and make them available to something, leave it to somebody else to figure out how to present them properly.
CHUCK:
The other thing is that I don’t have to go and program my HTML so that it knows what to do with stuff. The JavaScript is smart enough to pick it up and go ‘oh, that’s what I’m looking for; now I’ll just do my thing in there’.
WARD:
And the metadata helps you connect the dots.
CHUCK:
Yup.
WARD:
The metadata helps you say, “Hey Angular, put these two things together. Put this – that’s how this template goes with this component. And oh, by the way, you're probably going to need to know what services need to be injected,” and maybe some other stuff you need to know. It’s just a way of communicating with the Angular framework about the glue that’s necessary to make it come to life. [Crosstalk]
CHUCK:
Yup.
JOHN:
When you look at this diagram, you see the template and the component and they’ve got this – I’m trying to visualize it for folks who might be listening only – you’ve got a template and a component and you’ve got this arrow from the components and template, and another arrow from the template [inaudible] component like in a circle, mostly like a cycle diagram. It’s showing how the component talks to the template and the template talks back to the components through this metadata and through bindings, property and events bindings.
What strikes me about this, and [inaudible] when I reviewed it is we used to draw a very similar diagram in Angular 1 which had something between the template and a component. That thing that used to be between them was this dollar sign scope thing. That’s completely different here; it’s still – the metadata is not scope, not at all, but what the problem that scope solves in Angular 1 that bind a view to the controller is being solved through the property binding which is established through this relationship with a component and the template.
CHUCK:
Yup. I was just going to say one of the thing that I really liked about short-hand here with the metadata is that all of the dependency injection is then broken out so that I just know what I got and it’s one place, it’s easier to read than the really long array with strings and other variables and [inaudible] that I’m sticking in there so that it knows where to hook everything up.
WARD:
Yeah, the things that are supposed to be easy are easy to write. That’s the goal. You can go crazy if you want; when we dive in someday, in-depth, we’ll learn about all the nifty extra sauce you can sprinkle on here to do something funny, but the simple things would be simple.
CHUCK:
Totally.
WARD:
That brings us actually to databinding.
CHUCK:
Yup.
WARD:
People are using databinding all along in Angular 1. The databinding system is different. I think we should devote a show to it at some point where we really look at how it works, but it’s certainly a concept you have to understand. I think the big differences are that there is a sense of direction. We were played fast and loose with that in Angular 1; in Angular 1, you just lay a binding in and don’t think about which way the information flows and in Angular 2, you do.
So you think about property bindings, of – I’m pushing some of the information from the component into the template; that’s how values appear. Then coming from the template back to – your listening to things happening. You're listening to events in the template and you're moving information back so there’s a much clearer notion of a cycle. I think that’s the difference; I think another really huge difference is – I’m just going to lay it out there without being able to spend the show talking about it but a huge difference is that we’re not actually binding to attributes anymore.
This may shock you but those little things that we see in HTML that look like attributes, we’re not actually talking to them anymore. We’re actually talking directly to properties of the dom object. This may just o right over your head for now in terms of the implications, but it is actually one of the reasons that the whole thing becomes simpler and more predictable, simpler to use. I promise we’ll get to that in the show but the key point at this point is just to say ‘hey yeah, there’s databinding’.
You need to know about databinding.
CHUCK:
Alright. This is where I have a few questions because I’ve heard all kinds of things. All the Relay folks or React folks are going ‘one-way data flow and blah, blah, blah’ and ‘my life is better because it’s better’. I was like, “Okay, my understanding is that they're getting rid of two-way databinding in Angular 2, and right there it says two-way databinding.”
When we’re talking about databinding, not to get into depth on how it works but is it one-way or two-way or evented – what’s going on there?
WARD:
To that end, you see that there’s a very clear data flow; that’s what the circles are, that’s why there’s a separation of property binding and event binding. In other chapters, we really dig in and we say what’s typically involved in maintaining the relationship between a text box on the screen and a property in your control? What’s really involved? What do you want to do when you're doing forms over data? You want the information that you have about, say, a hero’s name, you want it to appear on screen, you want it to be able change that hero’s name and have it go back. That’s what you want. Getting it on to the screen is what property binding is. That’s one way from the value and the component on to the screen.
But when I type in the text box, what happens? Keystrokes go in, events are raised. You have an event binding that’s picking up those keystrokes and floating that information back into the component.
CHUCK:
Aha.
WARD:
Everything is moving in a single direction. Now I can – and we’ll show you how – I can write those as two separate bindings in Angular 2 and just make it entirely literal. Try to do that; try and write two separate bindings for every property that you have on a complex form and you're going to drive yourself nuts. That’s no fun because whether you have two-way binding in the system or not, you have a two-way binding problem mentally. I want to coordinate the name in the controller or the model with the name on the template, right? I got to do it; that’s what forms over data’s all about. Make that easy for me, will you?
So they did; what they’ve done is they created a syntax that realizes that this is a pattern you see over and over again. They simply made a syntax that allows you to achieve that effect in one simple binding statement.
CHUCK:
Okay. [Crosstalk]
WARD:
The ng model statement combines these two things into one syntactical notation.
CHUCK:
Right, so it’s one-way one way and one way the other way, and you have a short-hand that says put both of them in.
WARD:
Yup. Because I need them both and I know exactly what the pattern is. And there’s no – a framework’s here to help me. It’s not here to make me work. [Crosstalk]
JOHN:
At the end of the day, all you really care about is that you can enter data on the screen, it goes to your model and then if your model is talking to some other place in the screen, it reflects it there, too. So we don’t really care – maybe we do care and it covers how it all happens sometimes but whether it’s one-way, two-way, unidirectional, blah, blah, blah, I can type my data and it actually is propagated wherever it needs to go. That’s what I care about.
CHUCK:
Yup.
WARD:
So it’s honest under the hood; it’s honest unidirectional data flow under the hood but if somebody has to get work done and has 50 input boxed to deal with today or select boxes [inaudible], I’ve got a notation that won’t drive me crazy.
CHUCK:
Right. So then if it has to update it in several places on the screen, then it does the property binding on all of those and then there’s only one that does event binding back to the component that will do the updating.
WARD:
That’s not quite so, Chuck. That’s a very reasonable thing for [crosstalk].
CHUCK:
I can set it up that way if I [crosstalk].
WARD:
You potentially could; under the hood, what’s happening is you're setting up a listener for each individual text box. That’s how it’s coming back.
CHUCK:
Right.
WARD:
Actually, who knows what they're doing deep, deep down? Maybe they take a performance trick like you're suggesting; maybe that isn’t a performance advantage and they do that – we don’t have to care.
CHUCK:
No.
WARD:
What we need to know is that I honestly is unidirectional flow, property binding in and event binding out but they’ve made the syntax simple so that we don’t have to be – have that squished in our face but we can write the way we want to.
CHUCK:
Yup.
WARD:
But the very notion of databinding is fundamental in what we do here and that’s what we got.
JOHN:
I’m just thinking – I’m looking at the diagram again saying if I’m starting here from scratch, what do I need to know? What does this mean for me? What I like about this is you’ve got a very clear picture of a directive hanging off to the side so they're not going, they're not dead. There’s this thing called a directive that’s got its own metadata, just like a component has its own metadata. [Inaudible] The directive could also be part of a template; that’s a way – what’s the difference and how would you describe [inaudible] in a directive which you can have content, and a component which can have content?
WARD:
The way that I like to think of it – first of all, technically under the hood, the component is actually a kind of directive. Let’s separate those things up for a moment. They key thing that you can see about a component is that it’s intimately tied to a template. A component – it is about the templates, about driving a template and the visual representation of most component is as a tag.
You were talking, Chuck, earlier about that hero list tag that you saw in the example? That’s the visual representation of a component. That’s saying, “Hey, there’s a template out there. You should use me like an element.”
CHUCK:
Yup.
WARD:
The HTML standards committee doesn’t have a hero list element but we do now.
CHUCK:
They should.
WARD:
Yeah, right. So there you go. So that’s the role of the components, to control the template. But sometimes, we don’t want to have our own template; we want to be able to manipulate HTML without actually having a template.
For example, one of the most prominent examples in Angular is the repeater which is called ng-for. Basically –.
JOHN:
Wait, did you just announce Angular 4? [Laughter]
WARD:
There you go. Everybody give [inaudible] I know, I’m completely confused about that.
JOHN:
F-O-R, correct?
WARD:
F-O-R. Thank you, John. But the idea of a repeater is I’ve got some HTML in there. They represent a mini template for representing, say, a hero. If I’ve got five heroes, I want to see that template five times.
So what is it that takes that one chunk of HTML that you have there that is what a single hero should look like? What is it that takes it and stamps out a new hero five times for each of the five items on my list. That’s modifying HTML and that’s the kind of thing a directive can do. The directive itself doesn’t have a template; it is given some HTML to work on and it modifies that HTML.
That’s the role of directives and that’s, by the way, the way we use directives most of the time when we wrote them in Angular 1. Didn’t we use them to embellish some existing HTML and make it do something it couldn’t otherwise do before?
CHUCK:
Yeah, pretty much.
WARD:
That’s the distinction. A directive is for – is a modifier, an HTML modifier. Whereas a component is more like ‘here’s a thing that I want to represent visually’.
CHUCK:
I have to say that now that you’ve explained a directive that way where it adds to or embellishes some HTML to do something that it wasn’t originally or initially set up to do, I can see where a component then is a special case of this because essentially, it does. It embellishes or adds to existing markup but its job is specifically to work out things like bindings and also to set up the behavior within that space and own and understand it.
WARD:
I think that’s dead on.
JOHN:
So we covered directives, templates, components, modules, metadata and a little bit of databinding.
CHUCK:
And directives.
JOHN:
Right, and we get down to what’s number six on Ward’s architecture list which is services. There were five thing in Angular 1 that were services; we had the content provider, values, factories and services. Can you explain what a service is in Angular 2, Ward?
WARD:
The first thing to know about a service is that that is our name for it. There is no – unlike in Angular 1 where there actually is a .service, you won’t find a service – there’s no specific service constructor contract in Angular. It’s our idea about what it is we’re trying to achieve from this architectural perspective. It’s something – in this architectural diagram, the service is something that we need that does something of value. Usually, - think of the things that are of value, like I need something to go get data or I need some configuration information or I need a logger. If we build up these applications, there are things that we need to do. They're often little things but they're important to us.
Whatever that thing is, we should recognize that it has an independent role. It’s providing something of value, it’s providing a service to our components usually or directives or something so that idea of [crosstalk] – go ahead.
JOHN:
What is an example of a service that you commonly see in Angular 2 or that we’re starting to see?
WARD:
Get data – a data service, a logging service, the initial configuration. Maybe a price calculator.
JOHN:
So would this be safe to say this is a great place to share data between components in memorytype data?
WARD:
You can also have a stateful service like that exactly. For example, your data service might cache data, so one of them got the heroes and another component wanted to also get heroes, it wouldn’t necessarily have to go immediately out to the data base, it could ask a service for its cached heroes.
JOHN:
What strikes me about this stuff too, Ward has said when you define a service in Angular 2, there’s nothing to tell it it’s a service.
WARD:
Nope, there’s no [crosstalk].
JOHN:
It’s just a class.
WARD:
It’s usually a class, it can be a value. I can make pi’s – if pi’s a value, I can say ‘hey, that’s my pi service’ or some kind of a function. [Crosstalk] Exactly, my Apple Pi service. [Chuckles] The key thing is if you have something you want – most of the time, it’s actually very convenient if you can put that thing you want in a class because Angular likes classes, so if you put it in a class, it’s very easy to make it go into something else, very easy to consume.
So let’s just say that 90%+ of anything that we have of value that we think of as a service that we want to share is going to be a class, that’s great, but this is an architecture diagram so in this case, service isn’t so much as you say, John. You won’t find Angular 2 service anywhere. There’s not an API for the service. It’s an important idea to construct. It means I’ve got something of value, typically a class. Now, I want to use it – how the heck do I use it? I got a price calculator, I’ve got something that goes and gets data; how do I use it? [Crosstalk]
JOHN:
[Inaudible] the number eight or whatever.
CHUCK:
Yeah. Before we get to number eight, one thing that would be helpful – I keep going back and forth because a lot of developers that I know – all the rest of these, there’s a pretty settled way to build them. You’ve got your components and you build them in this particular way. You’ve got directives that you build in a particular way. You’ve got your templates that you do specific things with. With services, you’ve left it wide open. I understand that it’s wide open for a reason because you can really do anything that serves to bridge a boundary either between you're Angular application and something else or between different parts of your Angular application. But I’m having a little bit of trouble visualizing what the code actually looks like other than class foo service then a whole bunch of functions in it. Is that it?
JOHN:
That’s it!
WARD:
Supposed you had a sales tax calculator, you're doing an order entry system and you have something that wants to present – takes somebody’s order and you're going to have a component to represent that. Are you going to write the sales tax calculator right inside that component?
CHUCK:
No way. I get that; it was just visualizing what this file looks like, like what the actual structure of the code it. I think just saying it’s effectively a class with a bunch of functions on it, it’s just a collection of functionality that you just collect together and put into a service so that it works nicely together. It really gives people that understanding so if you're trying to visualize if there’s any kind of contract or any kind of API that your service is going to have, effectively that’s it. It’s a module or a class that just encompasses tax calculation or encompasses Ajax calls to the server to get a particular type of data or any data or all data.
WARD:
Exactly, and when you look at these services in any of the service classes that we give examples of, you cannot tell they have anything to do with Angular at all. They just look like work. They do work.
CHUCK:
And you can call them from anywhere else and you would call them the same way. Tax calculator figure out tax on amount.
WARD:
Yup. It’s just a class. [Crosstalk] Nothing that says Angular about it. Go ahead Chuck.
CHUCK:
Yeah, I just want to make sure that people understood. There’s not an example on the page that I’m looking at, this architecture document, and that’s because it is. It’s just a class with functionality in it.
WARD:
Do you think they should be? Because that’s something we can do.
CHUCK:
I don’t know. The reason why I was going back and forth is that I know a lot of people that will copy the example and then modify it, and I worry a little bit like if you put a data service out there and then somebody else comes along and wants to build a tax calculator that they might look at it and go, “Okay, now I’ve got this thing that makes ajax calls. Now what?” because it doesn’t fit the mold for the other one.
WARD:
I think if we just threw it as something that adds ten percent on a price on there as it sounds, tax calculator just has a one-liner function class that might help it drive it home.
CHUCK:
Yup. And I think if you put maybe two or three examples in there so you did have the service where it’s making jQuery call or jQuery ajax calls or something else where it gives the specific examples – here’s what a data one would look like; here’s what a tax calculator one would look like – your logging service is probably going to look a lot like the data service where it’s calling out and logging stuff. That can give people an idea ‘okay, this is how I would approach these different issues’. It becomes pretty apparent then – the message bus if I have a message bus within my Angular application, then it’s making calls to an internal API so it’s within the boundaries of my application whereas these other ones kind of pat out the external boundaries of the application.
WARD:
Yup. This is a wonderful feedback and I hope are [laughter].
CHUCK:
Anyway, you were moving on to how you get these services into your components, which I think is really a critical thing if you're not putting the logic directly into the component.
WARD:
Right. We could [inaudible] it up; it’s a class, we can [inaudible] it up but we know not to do that. We know from Angular 1 not to do that. Angular 1 had a dependency injection system and Angular 2 does as well. So it is – usually, services are injected through the constructor so you create a constructor for you class that takes as parameters the services that you want to inject.
That’s the consuming side. So I’m a component and I want my sales tax calculator, I simply say I want it. Angular has to know about it. You have to tell Angular about it and so at some point somewhere, you have to register that sales tax calculator as a service that should be available to anybody that asks for it.
There are a variety of ways in Angular 2 to do that, most of which look pretty simple. I think that’s probably – the dependency injection system is a great topic for another talk. I think it’s probably sufficient to know that that’s here and that it’s fairly obvious what to do to wire it up. I’m happy that – does anybody feel like they need to go deeper right now?
CHUCK:
I don’t think so. I think we talk a lot about how it visually appears in your code during the metadata section, and if you’ve been doing Angular 1, you should have a pretty good idea of how dependency injection works. It appears to work exactly the same way that you would expect it to having done Angular 1.
WARD:
It can work exactly the same way. The nice thing is that it’s actually richer than the Angular 1 version in that you can have the multi-level dependency injection system. What that allows me to do is – I don’t want to do this without actually diving deep into the subject – it allows me to scope the service, to say that this particular instance of the service is only available from this part of the application tree down.
Imagine if you will, I had an application with multiple modules. I have one in them that takes orders; I have another one that deals with customers. I have another one that deals with inventory. In Angular 1, I pretty much have – if I have an inventory service, it’s available to everybody across the board. The customer service shouldn’t have that access to that service – I’m sorry, the customer module and the order entry. Maybe they should, maybe they shouldn’t but there’s no reason why they should be thoroughly exposed across the entire application when it really only belongs in one place.
What I can do is I can say, “You know what, this customer service that I have, that’s only available within the customer component and all of its sub-components.” It’s only available in that part of the tree and I can make it do that. That’s one of the values of a hierarchical injection system.
There are others and we’ll have to do that in another show but it allows us now to compartmentalize our application which is somewhat hard to do in Angular 1 but it’s really easy to do in Angular 2.
I can build whole feature areas that are dedicated to a specific problem and I can make those things stand alone and have them – and not pollute anything else so I can just pick that piece up and I can put it in another application or I can relocate it within the existing application. It stands alone. It’s one piece, and that ability to draw a boundary around a feature area is really a fine architectural principle and we can do that super easy in Angular 2.
CHUCK:
Yup. I really like the idea of not just – basically limiting it to which areas you want it to have it. You could do that with dependency injection in other systems but it looks like they’ve really thought this through so you can control where it’s available, control where it’s not and not clutter things up so that you have any more concerns in the area that you need.
WARD:
Right, and so when Lukas and his team is working on the customer feature area and trying to drive that out, and he has his schedule and his team has its schedule and delivery schedule and all the things that they need to do when John is working on the order entry system and he has his schedule and his requirements.
The two teams can work independently, not step on each other, build their components, build their services, test them independently, run them independently without having to mess with each other and then bring it together in a sort of ‘under a shell’ application that gives the user the common experience to jump from one ware flow to another. But under the hood, we know that these are actually being worked on by different teams, evolving at different rates, improving at different rates, responding to differences of requirements and they don’t have to spend so much time trying to – John and Lukas working out when they're going to do what with each other.
CHUCK:
Yup. So we’ve talked as long as we usually talked and I think there’s some more to talk about with architecture in general. I think architecture’s an overloaded term where we talk about all of the different pieces that we have in order to build our application, but there’s also architecture in ‘which of these belong in the same files as others’ and ‘how do we set all that up’. Modules definitely get you to part the way there but I’d love to do another talk about – in general, you put your components into their own files and you put your directives into their own files. We talked a bit about in-line templates and things like that in the last episode, but overall this has been really helpful.
WARD:
I think John is going to have a lot to say about how to structure your application in a meaningful way because I think there’s a style guide in your future; isn’t there, John?
JOHN:
There’s certainly is [chuckles] and we’re already evolving how things are looking and how apps – how we feel that apps really should be designed with Angular. The good thing is a lot off the concepts that are coming out with the Angular 2 style guide are really – they're actually very similar to what’s in the Angular 1 style guide.
LUKAS:
If you don’t mind, I’ve been spending the last 40 minutes scribbling in Photoshop; I’d like to just run how I see this by John and Ward and just see if I’m on the right path.
So in Angular 1, I have a graphic put out; it’s on a bunch of my presentations and I just called to Angular a big picture and there’s ironically eight pieces in the graphic. It all starts around the view, scope and the controller. I think everything converges on the particular pair. For instance, if you're setting up a route, you need a view and/or template and a controller. If you're building a directive, kind of the same thing; it all comes together to this view controller pair where, in Angular 2, now that becomes essentially your component with your template, whereas you had scope before that’s now split in half and you have property binding and event binding.
Component plus template equals view and controller, and scope equals property binding and event binding. So far, so good. Yes? No? Maybe.
WARD:
I thought of this – I think it’s really close, Lukas – I think what is confusing to me is the scope but then that always confusing to me. That was always a trash can for me. It had a whole bunch of things in it; some of it – it’s certainly was part of the coordination of the binding between controller and view. It also had all the stuff about a [inaudible] event, broadcast and the digest and all that jazz. [Crosstalk]
JOHN:
Something in Angular 1 didn’t fit somewhere else or went into dollar sign scope.
WARD:
It went into dollar scope [laughter] and it was also an object; it was an object that you touched. In Angular 2, that disappears. The things that – only the digest cycle [inaudible] for reasons, we’ll talk about it in another show so that’s not there. There’s a much richer mechanism for managing events and it’s not – it’s a separate construct that I didn’t mention so you don’t need that and the dollar scope. Now, we have a binding system in which you wouldn’t – you use the metadata to describe how the bindings – what the parts should be to some degree so really, dollar scope has no role anymore. It doesn’t need to exist because anything it did before has been – has evaporated. [Crosstalk]
JOHN:
Either that or it’s moved into something that was [crosstalk] more tended for.
WARD:
Right. There’s no digest, the event management stopped at some place else; in a better place I want to say. [Crosstalk]
LUKAS:
It’s in Heaven. We killed it.
WARD:
Oh no, we didn’t kill it! No.
JOHN:
But we should talk in our future shows, to talk about where events go. [Crosstalk]
CHUCK:
Yeah.
JOHN:
So that’s events made of databinding where we talk about that piece of scope that’s now there. Since we’re all different with Ward on this, I think your diagram is okay if you look at scope and your diagram as the way the controller and the view communicated with each other. That’s the only piece you're talking about in the diagram that I think that makes sense. But I agree with Ward that since scope does 90 things in Angular 1 that it’s probably not entirely accurate if you look at it from a holistic view.
WARD:
And in Angular 1, the cope object was something you could actually take a hold of even for binding purposes. You – for binding purposes, you put something on the scope. If you want the name to appear on the view, you had to put it on to scope; even in controller [inaudible] that was happening underneath. There is no scope object anymore; that’s not how the binding works.
JOHN:
But it’s interesting because looking at this, he’s got the view in the controller [crosstalk].
WARD:
He’s got the parallels right. [Crosstalk]
JOHN:
Yup, and he’s got the directive; it’s still a directive. Config is kind of what metadata was, although I [inaudible] as the metadata on the directive in Angular 2, the equivalent in Angular 1 was probably the DDO, all that stuff we piled into a directive before.
Then the service in Angular 2, which is really just a class with an injector, that really – let’s just look at it as basically the coming together of the consolidation of the file to bring kinds of services that were in Angular 1. Yeah, I can see this.
WARD:
Right, then we didn’t talk about routing. You have routes in your diagram. I think we should probably put some of these graphics in the film notes actually; that will help people look at it.
JOHN:
You’re so [inaudible]. Hopefully, Mr. Chuck can put those in the page for us.
WARD:
Yeah. We didn’t talk about routing because that’s going to be a show of its own, but where you have routes there, Lukas? Yeah, there are going to be routes in Angular 2.
LUKAS:
Yay! I can put it back to my diagram. [Laughter]
CHUCK:
Your diagram looks like an airplane.
JOHN:
Nothing of a core Angular. So forget all the peripherals around Angular like ngAria and material design and all that stuff. Nothing that I’ve seen that was in the core of Angular 1 – when it gets down to ‘there’s a functionality I need’, none of that is missing in Angular 2.
CHUCK:
Right.
JOHN:
In some cases, it’s almost exactly the same the way you deal with stuff. In other cases, it’s just moved to a more appropriate area, kind of like events.
CHUCK:
Yeah, the other thing is that some of the things that we have talked about like dollar scope and stuff, it all got sucked up into the component and made basically automatic.
WARD:
Yeah.
JOHN:
Now, I’ll go negative on this for a second. The one really nice thing a lot of people tell me the dollar sign scope, and you guys know if you know me well enough, I don’t really like dollar sign scope. I tried using control [inaudible] just to abstract it to get away, but I’m thrilled to get rid of it entirely. But the one thing people tell me they like that dollar sign scope and I can see it, is that it gave them a tangible way to say ‘okay, this is the thing that gives me databinding’. So if I need to data bind, I know exactly where to go.
In Angular 2, there is no thing that I can touch and feel that gives me databinding but – before I
answer [inaudible], Ward, how do you feel about that? How would you answer that?
WARD:
That’s hard for me because I never wanted a thing. Basically, I wanted my controller in Angular 1 and this is why I’d use controller [inaudible] or I wanted my component in Angular 2 – it has a surface. It has properties that it exposes like name or a model object or a title or whatever it is. I just want to be able to bind to it. I don’t have any great ceremony about that; if I got it on my – if it’s public on my component, then you can bind to it if you want to.
I don’t need any special object to hold anything. To me, I look at a dollar scope and hated it on site when I saw it.
CHUCK:
Yeah, my thing is that – I feel like I’ve got the power when I’ve got some explicit object that I can go and monkey lift and that’s – I see why people like that in dollar scope but for me it never passed the sniff test to go modify it directly because the controller always had a way of effectively doing that anyway. So by going and directly modifying dollar scope, I had to – yeah, it just didn’t pass the sniff test for me because it belonged somewhere else.
JOHN:
I’ll go back to my VB days; it was like the tag we used to have back in the late ‘90s and VBs. It’s like, “You can’t figure out where to put this data? Create a tag property.” [Laughter]
WARD:
The one thing that people used to tell me that they like dollar scope for that made some sense was that they would often use the fact of scope inheritance to communicate from one controller to another by putting things in the scope and picking them up some place else. That was always an anti-pattern in Angular 1, but it sure is convenient.
CHUCK:
Yup.
WARD:
Awful lot of people did it. Obviously, without a dollar scope, there’s no way to cheat and do it that way but there is still quite a variety of ways of doing – actually, there’s every bit of these ways to share information between components at any level in Angular 2 that’s a great topic for another show. If I had to distil it down to one thing, one of the mechanism that you already have is the service. If you need to share a state among a bunch of controllers, create a service and have them all inject and share it. Bingo!
CHUCK:
Yup.
JOHN:
I’ve got to say something here. I tweeted out while we were talking; I tweeted out the link to the diagrams that we’ve been talking about and a couple of people have commented. Here’s the tweet from a guy named [inaudible] on Twitter. He says, “Fantastic documentation. The diagrams are so simple to understand. I went through the whole doc in one hour.” Kudos for putting this together. I think people are going to appreciate this.
WARD:
Tell him the check is on the way. [Laughter]
JOHN:
Wait – the picture on that guy looks a lot like you.
WARD:
Oh! [Laughter] I do have a little lovefest with myself. [Laughter]
CHUCK:
TMI. Alright, let’s go ahead and get to the picks. Lukas, do you want to start us off with picks?
LUKAS:
Sure. I read a book this week that I think is a life-changer. It’s the War of Art by Steven Pressfield.
CHUCK:
Oh, so good.
LUKAS:
It’s about three hours on an audio book, 3x – it took me an hour to get through it and it changed my life. He talks about resistance and – I don’t want to spoil it, but I think everybody who is creative or entrepreneurial or just wants to do more better should listen to this book. It’s phenomenal.
CHUCK:
Can I spend another 3x hour of your time?
LUKAS:
Yeah.
CHUCK:
Do the work. Steven Pressfield.
LUKAS:
Awesome.
CHUCK:
Both books are excellent.
LUKAS:
It’s unanimous. [Chuckles]
CHUCK:
Alright. John, what are your picks?
JOHN:
First, in the season of the holidays here, I want to pick my awesome hosts/co-hosts for this show. I really enjoy the year and a half now we’ve been on the air. You guys are pretty darn awesome, a great group of [inaudible] people and [inaudible] the conversations, and all of our guests as well.
As far as non-sappy pick, there’s a book that I read recently – yup, I can read, too. [Laughter] It’s called the Five Dysfunctions of Team Leadership. I’ll put a link here in the show notes. It’s a fable about a leadership team and how they're so amazingly dysfunctional. I read it and wow, you can just see so many ways it relates to companies that I’ve either consulted for or worked for directly. I’m not just picking up people because there’s good things and bad things that are in it, but it’s amazing how you can pick these things out and it really taught me some information about how I can talk to leaders. I think it’s a great thing [inaudible] whether you're working at a big company or a small one. The way we communicate with people who pay our bills is really important. That’s a key piece that often gets lost in technologists. Communication’s a key aspect to that.
Outside of that, I have some general picks and that’s the stuff on the Angular docs; the one with architecture diagram that Ward’s been pointing out that he was the main author on or, in fact, I think he was the only author on. Also, there’s some great developer guide and tutorials up there in the main docs. There’s a blog post from the show notes which is the announcement of Angular 2 so get it while it’s hot.
CHUCK:
Nice. I just want to say that you picked why things like Dilbert and the Office are so funny with that dysfunctional leadership pick.
JOHN:
Yeah, I read this book and I got to tell you, it was almost too close to home sometimes.
CHUCK:
Yeah. It’s funny because my wife – I used to watch The Office every time it – I was like there when it came up, I wouldn’t even DVR it because I loved it so much because it was so funny. She was like, “This is the dumbest show ever,” and I was like, “Yeah, but I’ve worked with all these people.”
JOHN:
The worst part about that show is I could never watch it. I watch two or three episodes but Steve Carell, the guy who plays in that, I actually worked at a company where that guy was basically the guy who owned the company.
CHUCK:
Uh-huh.
JOHN:
It was just maybe too close to home to me to watch and going, “Oh my gosh, I lived this. This is terrible.”
CHUCK:
Yup. Alright, Ward, what are your picks?
WARD:
I’ve been so hands down the last week on my team’s contribution to the beta that I don’t have anything from the side but I do have this – one thing that I learned during thing log is just how important my wife is to me. [Chuckles] And so my pick is my wife because man, I was just hard to live with and she somehow manages to do it and make my life easy. So everybody, if you could have a wife like mine [laughter] but you can’t have mine. Mine’s taken.
JOHN:
Oh wait a second – I think Lukas just typed in that his pick was your wife, too. [Laughter]
WARD:
That’s what I was afraid of. [Laughter]
LUKAS:
Seriously?
WARD:
If we can talk? Great.
CHUCK:
That’s awesome.
LUKAS:
You’re wife’s not listening, man, and she’s in the room. You're in trouble. [Laughter]
JOHN:
[inaudible] having a great, strong support system at home is a key thing when you're an overworker like some of us are.
CHUCK:
Yup. Definitely. Alright, I’ve got a couple of picks here. Mine are much less related to Angular. The first one is I listened to this podcast this last year and it was amazing and I loved it. It’s Serial and season two is coming out, so go check it out if you're interested. It’s about Bowe Bergdahl who’s the guy that – there was all the controversy over President Obama treating some terrorist out of Guantanamo for a deserter if you heard that news story this is the soldier that left his post and it’s really interesting. The first episode is basically him telling his story in his own words. They have a bunch of recording things; they explained where they get them from and that they got permission from him to air them.
They don’t ever talk to them directly or at least that was the impression I got from episode 1. Episode 2 comes up tomorrow as we record this and I’m really, really fascinated by just seeing what makes people do what they do and how the whole thing got blown up from one soldier disappearing and then being treated for and gotten back five years later, and all of the things that are involved with that. I’m really interested in knowing more about the story.
WARD:
Can I just [inaudible] there for a second, Chuck? I think Serial is one of the most brilliant series ever. It’s been off from This American Life or something like that. Last season was amazing. This one will be, too.
CHUCK:
Yeah, and I know that this is a much more politicized story but so far they're just telling the story. So they're not pontificating it all on whether or not the President was right to trade back for him. They haven’t really discussed anything around the different viewpoints there; it really is about the story which, in my opinion, makes it so that I can stomach it without disagreeing in one point or another and I can really just find out what happened. The last one was about a murder trial and that one was also really, really interesting.
I think Adnan from season one, I think he’s actually getting an appeal. But the thing that’s really interesting, too, is that they never tell you what to think and so you have a whole bunch of people on both sides of the isle that think that this kid committed the murder or didn’t commit the murder, and that he should’ve gone and he shouldn’t have gone to jail so they really do just tell the story and leave the opinions up to you.
WARD:
I have a feeling that’s exactly where this will play out. We’re just going to her about all the different ways in which this little guy’s life has been perceived and how their perceptions in the political football turned his life inside out.
CHUCK:
Yup. The other thing that’s really interesting, there was a talk at Podcast Movement this summer by the main reporter. I don’t remember her name but she gave on of the key notes at Podcast Movement. So for an hour, she just talked about it and answered questions from the audience about serial and I’m hoping they’d do that again this year but I doubt it, but yeah, lots of interesting stuff going on there.
The other thing that I have, I’ve had this Pebble Time Steel for a while. There are a lot of things I like about it. I’ve had this love-hate relationship with the watch band that came with it but it just got an update this morning and it turned on all of these health tracking features. So now, I’m getting steps counted and all of these other features out of – basically out of my watch. It’s showing up in Health Kit or the health app on my phone and I’m really digging it so I’m just going to pick the Pebble Time Watch again. [Crosstalk]
WARD:
It’s that new hair you're growing, too? Did the Pebble Watch do that?
CHUCK:
[Chuckles] It only grows on the bottom half of my face. Those are my picks.
Alright, well I’m really looking forward to the talks we’re going to have in the future. Thanks everyone for coming. Sorry for my kid’s screaming. We’ll catch you all next week.
[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!]