WARD:
Alright... Can you hear me? This is Ward.
JOE:
Is that Ward? I couldn't tell. Your voice is not distinct at all...
WARD:
Not distinct at all...
LUKAS:
Well, maybe, I can do Lukas' voice... [Laughter]
LUKAS:
I don't understand!
JOE:
I don't know, this is Lukas' Pro Tip!
LUKAS:
Pro Tip!
AARON:
Yeah!
LUKAS:
La la la la!
[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.]
[Does your team need 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 -AngularBootCamp.com.]
[This episode is sponsored by Wijmo 5, a brand new generation of JavaScript Controls. A pretty amazing line of HTML5 and JavaScript products for enterprise application development. Wijmo 5 leverages ECMAScript 5 and each control ships with AngularJS directives. Check out the faster, lighter and more mobile Wijmo 5.]
[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!]
JOE:
Hello, everybody! Welcome to Episode 47 of Adventures in Angular. On our panel today, we have Lukas Reubbelke.
LUKAS:
Yo, yo!
JOE:
Ward Bell.
WARD:
Hello there!
JOE:
And, I'm Joe Eames. I'm your host. We have a special guest today, Patrick Stapleton.
PATRICK:
Hey, guys!
JOE:
So Patrick, the topic today is going to be like a general Angular 2, migrating an Angular 2, etcetera. But before we get into that, we're going to do the talk a little bit about yourself and your background and just give us an introduction to who you are.
PATRICK:
Yeah. I'm Patrick Stapleton, but I'm also known as PatrickJS. That's because my middle name is John and my last name is Stapleton, so it's actually is JS.
JOE:
Wow! That's the coolest name ever!
PATRICK:
[Chuckles] Yeah.
JOE:
Man!
PATRICK:
[Laughs]
JOE:
Why can't I be JoeJS?.
[Laughter]
PATRICK:
Yeah. That's like, that's my thing. I do corporate trading in open source at a small company my friend and I started called the "Angular Class". I also work with Angular team on server rendering Angular 2, and talk about JS with Netflix on Angular 2 Integration and examples for that.
I guess my background is more of a... previously, I was also a CTO at a small startup in San Francisco called "Keychain Logistics", Andreessen Horowitz backed, Wilson backed company. Before that, I was also an instructor and an in lawn of Hack Reactor, which is a bootcamp. During that, I also won a LAUNCH Hackathon and also created this thing called "Reddit Insight", which is downloading Reddit and then running an [incomprehensible] lyrics on top of it. That was actually like insuring popularity in the... It was actually the top 50,000 websites viewed that day. That's me.
I've been doing Angular for about 2 years now.
WARD:
I've seen your picture, and I don't... You're too young to be a CTO, I'm just saying.
PATRICK:
[Laughs] Well, that's kind of life story. It's more of an opportunity I took. But yeah, that's how all there started.
WARD:
Well, you can just dye your beard gray, that will help.
PATRICK:
[Chuckles] Well, my hair is starting to gray.
LUKAS:
Oh, that's stress.
PATRICK:
Yeah [chuckles].
WARD:
Wow! What do you think about Angular 2, and where it is headed?
PATRICK:
Angular 2 is really, really interesting because it's more Enterprise great. You think of a frameworks in a spectrum of far left being really good for smaller apps and far right being really good for Enterprise. Then Angular 2 is more so on the right, and Angular 1 is more so on the left. This is why Angular 2 is getting a lot of flack with exact to [incomprehensible] with the examples because it's usually a lot of boilerplate because it's literally on off side right down, it's not done yet. Well, in Angular 1, it splits for a lot of smaller apps. And because of that, examples are just way simpler, and it's in production already so it's not like it's enough or anything.
WARD:
I'm curious about that Enterprise Small App Distinction, particulary since I've spent a lot of time in the so called "Enterprise", and they have a lot of small apps... mostly small apps. Actually, if anybody smaller than the -- we used to think of Enterprise as really big, but it's actually the Facebook or the social media things that are really big and making Enterprise small.
But that's around about why I've been asking, what the heck are you focusing on that is the Enterprise-y character that is missing in Angular as we know it today?
PATRICK:
I would say TypeScript static analysis, more so as static analysis. Like Angular 2 focus is having a really solid baseline being able to use statically analyze your code base. From there, you can even turn your application to an actual syntax, or you can even go really crazy there like some people do that into Enterprise. But the idea of Angular 2 right now is that they're trying to get the foundation that's extremely solid so that way, when you build attractions on top of it, it's a lot easier to reason about for tooling because you have that static analysis.
So I guess, when I say Enterprise, it's more of working with large teams and being able to work more independent because you have a better choice. And a lot of problems that you run into with Angular 1 -- and that is like typos with the Directives and everything -- would essentially go away because you could create a scheme up for the Directive or you have Types, and then you are able to infer what the Directive needs in order to interact with it, etcetera. So I guess, when I say Enterprise, that's what I'm trying to get at.
WARD:
Okay, well, I can't debate with that, Enterprise or not. But I get where you're going there. There's the thought that you're going to have large applications with large teams and that they'll all have more success if they have better tooling and they have the kind of type support that you get out of a TypeScript so that they can get some design time feedback rather than relying on runtime failures, and so they can write even fewer tests. And they write today, so that they will have to know whether they're actually working or not because the compiler will tell them, that kind of thing.
PATRICK:
Yeah.
WARD:
[Laughs]
PATRICK:
Yeah [chuckles].
JOE:
I'd like to turn the discussion a little bit into Angular 2 Preparation and Migration; getting ready for Angular 2 and maybe migrating your apps from Angular 1 to Angular 2. You think we can talk a little bit about that?
PATRICK:
Yeah. The minimum amounts of effort that you could put in right now is just switching to ES6. That alone will do wonders for you during migration because majority of the changes is just due to the language itself. If you want to take another step further, you could then start attracting your Services into Classes. I have a GitHub gist showing example of Angular 1 Service and Angular 2 Service (it's simple to do that), where it's using both the Angular 1 DI in one cloud and Angular 2 DI in the other one. That's literally the only difference between the two; it's the Dependency Injection.
If you look at the Files -- I'm going to post that in the show notes or whatever -- if you look at the File, literally, the only thing that's different is the top and the bottom part of the File where the Class itself is relatively the same.
WARD:
It's very interesting.
AARON:
That's actually like a really big thing to do to say, "Just use ES6". There's a ton of decisions had to be made there like should we use TypeScript or Babel? What do you mean by ES6? Because you mean something besides JavaScript native, like some sort of transpilers app. So, what are you suggesting?
PATRICK:
In any production app, you're always going to have [incomprehensible]; you're always going to magnify your code. While you're doing that, you might as well also add another steps and that's using something like ES6, Babel, or TypeScript. To make the transition easier, I would recommend Babel. But if you're willing to learn a little bit more about Types, then I would definitely recommend TypeScript.
AARON:
So once we're on Angular 2, are you recommending we use Babel on Angualr 2? Or, are you recommending we use TypeScript on Angular 2?
PATRICK:
You could use Babel in Angular 2, but I highly recommend use TypeScript just because you have the Type Dependency Injection. So, you could essentially specify...
AARON:
Yeah.
PATRICK:
You have this file Sugar where you specify the Type and then when you compile it down, TypeScript will automatically add a decorator to inject the Type for you, or to inject that Service for you.
AARON:
A lot of us aren't been able to do one conversion to Babel and one conversion TypeScript. So you're saying, it's easier to go from nothing to Babel, but ideally, we should go to TypeScript. It's kind of what I'm hearing it.
PATRICK:
Well, just going to anything like ES6+ there, the ES6, I guess the only options are really just, at this moment, just Babel and TypeScript. Anyone would help. But I guess I should say, like converting an application from Babel to TypeScript, it's literally just adding Types to the Constructor and that's the minimum amount that you need to convert it to from Babel to TypeScript. You don't technically need to -- because it's optional types -- you don't technically need to add Types to every single thing.
JOE:
So Aaron, you're a huge proponent of ES6, right?
AARON:
Yeah!
JOE:
You've done a lot of work with it. What do you guys think of the authoring scenario in ES5? I'm sure you've seen the examples of Angular 2 and ES5. What's your thoughts on that versus somebody that says, "Oh, I don't want to go to ES6! The Angular team promised that I could write in ES5." Maybe some thoughts about that.
LUKAS:
At ng-vegas, Bryan showed -- and I'm not... If someone wanted to use ES5, I don't care; there's tools there that will help you -- at ng-vegas, they showed this Tool, I think it's called "A.JS", but it gives you the same syntax that annotations give you, but you can use it in... Like it's similar, the set up is similar to what you're doing in ECMAScript 6 with annotations, but it's all wrapped inside this A library, you get some magic out of it, so that people who are in ES5 and if they have some reason why they need to stay there, they can stay there.
So, if you need to stay in ES5, there's tools for you. That's my opinion. Hopefully though, everyone is saying, "Yeah, I will use ES6". I know that there are like the Eric Elliots who hate anything to do with Classes and so they are going to avoid at least that one part of ES6, which is, unfortunately, what Angular 2 is highly dependent on.
JOE:
Isn't Ward in that camp?
WARD:
I am one of the people who is fearful that Classes will be overused. Particular worry is Deep Inheritance. It isn't that I mind a single-level class, but what I see going on in the statically type world, is that people then are using Inheritance over Composition and they're getting this Deep Inheritance reason, you get lost. That's bad in the static world, and it's not so good here. And of course, you can do just fine with function-style JavaScript in both TypeScript in this new world. What I don't know is, it does seem that Angular 2 is resistant to that, is that a correct impression? It's resistant to your couching Services as functions as opposed to it's Classes.
PATRICK:
Well, remember that Angular 2 is built from the ground up with emphasis on Performance. Also remember that in the browser, the browser is V8 for example, and the engine that runs the browser, it actually looks for the Class Pattern and automize for that. So do it on internally, it's actually creating a Class Object in like C++ or whatever, and it's optimizing down there. That's why Classes are here to stay just because the Performance gain. Example would be Dart. When they were doing Dart and making the VM for that, they found that they were able to get twice the amount of speed compared to V8 because everything is statically typed and everything's using classical system, and they were able to replicate a lot of that in the virtual machine.
But more of on your question, Angular has always been advocating Composition over Inheritance. The best example of this is Directives. In Angular, you have this notion of Directives, and Polymer has this notion of a lot of Components. Now, in Polymer, they favored Inheritance. And because of that, you had to inherit like their Polymer class, then you are able to extend on top of it. In Angular, you just create a Component at the Directive side of that. Now, the pros and cons of the two, with Angular that's a Composition because you had multiple ones around each other rather than charging it. In Angular 2 and 1, you run two problem with having to prefix all your Directives, rather than in Polymer where you don't have to prefix your Directives because you know for a fact this is being like what properties are being what as opposed to Angular 2 where you actually prefix your properties because then you don't know which Directive is, like what your setting for which Directive.
That's like an interesting problem of the two paradigms. But Angular 2 is flexible on that. I'm trying not get too deep and too insane at Inheritance.
WARD:
Boy, that's a bookmark thing. I got to go figure out what the heck, where were you just going with that, but I think I get it. And I think, my worry about the Class thing is in same Inheritance and what in the way that's going to get people going down that route. But that's not necessary that they fall down that trap door anymore than it's necessary that they fall down in statically type languages. So, it's just a worry because, as you say as you started here, you talked about how there was disorientation to the Enterprise. To my mind, what we're sort of doing is trying to make it easy on developers who spent all their time in statically type languages to try and bring over their habits to the JavaScript world, which means not being true to the opportunities that take advantage of the opportunities and the style that's available in JavaScript, and that's worrisome. But, we can get over it.
PATRICK:
Yeah, you're definitely right. That's always been the case with Angular. Like it's always been the case that it's always trying to make it easier for more people for most languages. Example would be just Angular 1 itself with the notion like Factory, from Java, and just a lot of stuff, Patterns from Java that makes it a lot easier for people coming from Enterprise and other languages, but that's the whole purpose of TypeScript in general, anyways. But you're right, it's inevitable, like it's going to happen. The only way to prevent it is for all the influencers to applicate against it. So when people are learning Angular, they learn from whatever resources are out there. And if everyone keeps talking about "You should do this because of this," then they only know not to do that.
I know exactly what you're talking about because when I was doing corporate trading for this one company, there was one particular person that -- because we're teaching it in Babel -- he kept using Classes for everything. And then I was saying, "You could do that, but then look what happens. Now, you have to manage your Dependencies rather than having the DI manage it for you," because he was creating all these Classes and returning every Factories and everything. I'm showing him like, "You could do that. It's just that you only want to do that for several reasons, etcetera."
WARD:
I'm completely with you. We're going to have to help the community benefit as it comes over here, gain the benefits of the strong typing and the design time tracking, but shed their typical [incomprehensible] behaviors, and we can do it! It's just a challenge.
AARON:
My thought is, that words "Fear" is good fear, and I hope people heed what he's saying. I do think, however, the new Class System doesn't add any functionality to Inheritance that we don't already have in JavaScript, so I don't really run into an insane amount of over hierarchical Inheritance Chaining with Prototypes. And I know that Classes make it easier so that's going to bound the more with Classes than it would be with the Prototypical Inheritance. But because it's never been prolific with Prototypes, I'm not sure it's going to be prolific with Classes either. I think you'll get some Inheritance, but I don't think you're going to have these things we're all scared of, which are these never ending trees of Inheritance and you can never find the word that function that your Inherited came from. I don't think we're going to really see that. And if you do, just fix it. I don't think it's going to be a thing. Anyone who does, if it's on some major framework like if Angular does it or React does it, it'll all quickly become a dinosaur because people aren't going to attract migrate to something like that.
WARD:
Well, I certainly hope you're right. And I'm also hopeful that we will be continuing what I consider a fruitful pattern within JavaScript, which is Duck Typing, where you just sort of layer on functionality and borrowing from different things. And if it looks like a Duck and acts like a Duck, then it's a Duck.
So Patrick, what kinds of things change for the Angular developer to sort of, this is the Angular 1 developer who wants to shape his code, be ready to move, where are the things that you concentrate? I've seen some of your videos and you've been working on trying to get that thought across.
PATRICK:
The biggest thing is Services just because they could be refactored and teaches Classes. In Angular 1, you do the Modular Revealer Pattern, and that's essentially just returning object, and then that has just the methods, and then you could refactor that into a Class very simply.
The other place is Directives. This is another thing that people don't realize. But essentially, even though the API is really scary at times, essentially there is no best practice or opinion on how you just create a Directive, and because of that they give you just all the options in the world. In my ngvegas example, I showed that you could actually use the exact same syntax in Angular 1 and 2 for binding data. In Angular 1, you would do this with Scope and then in Object and then you say Data. From the right-hand side, you would actually greening data2=bind data. That way, from the Template, it looks like bind-data. This is semantic in Angular 2 where you're able to create alternative syntax rather than the whole bracket [incomprehensible]. It will actually specify what you're binding, and we could take advantage of that convention in Angular 2 and bring it over to Angular 1. During that, it would also make the interface in Angular 1 a lot simpler, too, because its best practices are ready.
WARD:
That was a really cool demonstration, which it comes about halfway through that video. I know we're going to have the link. But you did a number of moves there where you were showing the symmetry, almost the syntactic symmetry, between what you would write in Angular 2 and what you would write in Angular 1. I thought that was really good.
One of the other interesting things you did in there was you replaced, in the Directive, you replaced the link function with the Controller. Can you elaborate on that?
PATRICK:
It was kind of like a bad practice previously. Angular 1, it's very obvious, it's 5 years, and I've seen the community change its opinion and it's like... it was actually really wonderful because [incomprehensible], but essentially, the best thing about Angular is also one of the worst things, that's always been the case. One of the best things is that it doesn't hold that much of an opinion on you, and because of that you're able to be a lot more flexible. That's how we got the whole Module Folder Structure as opposed to just Controller Type System that kind of crazy after all, and that's because we don't have the restriction.
And because of that, the community just changes overall. Previously, the Controller, it was actually bad practice; you do any DOM equation in there, etcetera. But because we now know what best practices are for Components, it does make sense now to do that. And the difference between a Controller and a Link is that, in Link function, you have more control over there at the life cycle of your Component as opposed to Controller where it just gets engulfed before all the linked post-link, pre-link thing happens. That's also one of the downsides of Directive API at Angular 1; it's that it wasn't really thought up like life cycle system wasn't really thought up that it needed to be userfriendly. That's more of an afterthought just because there was a used case. This happens because the whole progression of time. And also, remember that another example is the Router. The first Router, the one made by Angular, it was actually only using one View, and that was actually by design because initially, Angular was advocating people to use more Directives, and that's what people are doing now. But the problem back then is that everyone was scared of the Directive API because it's pretty scary. We have talks about that, we have a book about it, etcetera, for good reason. And because of that, the community shifted to ui-router, which makes sense and that's great, and then just went full on just MVC. Because of that, everyone just shift, the community shifted the best practices to that. And then when someone else came around and said, "Hey, we should do everything in Components," suddenly everyone is saying, "Oh, that was a good idea. We should be doing that." But the problem with that was like the Angular team was kind of advocating that initially. It's just that there is no like best practices or good API because of that.
WARD:
Right. And the Directive syntax was meant to support a great many edge cases that maybe weren't the best idea, but that really complicated pipeline when this happen and that happen. It's just kind of crazy, isn't it?
PATRICK:
Yeah. And...
WARD:
And to be able to boil that away, a lot of that way at NG2, right? There are in this many moments to worry about. Is that a fair statement?
WARD:
Right. I mean, you're not bombarded with "Okay, I have to decide whether I'm going to have a Compiler or not."
PATRICK:
Yeah.
WARD:
And if I have link, too, I have a pre-link and a post link, and all of that crazy edge stuff.
PATRICK:
Yeah. So it's more thought up because of the experience of everyone in the community and learning what the best practices are now.
And another caveat with Panels and Journals that everyone keeps talking about is MVVM, MVC, MV whatever. What it really is is just MVC within MVC, and that's a thing that people kind of forget, and that's another thing that happens all the time; that everyone kind of forgets history and they are doing to repeat it. For example, the server is MVC, but then you create a [incomprehensible] app that's one part of your MVC app, and then on the front-end, your MVC app and then each component is MVC that's essentially how after structured. But people kind of forget that, that's whole other intention, that's all.
WARD:
I think I know what you mean there. But let me forward back at, do you mean that the UI is composed the unit of composition or this little MVC triads, if you will, and they're nested and you build up your app through nesting of these things through composition. Is that what you mean?
PATRICK:
Yeah, that's exactly right. The idea is that for us as humans, it's easier to reason about a problem if
it's smaller and if it's encapsulated. That's why something like the Module or Component somewhat is great because it's basically a smaller app, and it's easier to reason about that. And if we have multiple smaller apps, it's easier to reason about that. That's why it's composed of all MVC as sort of recursive because it's as easier to reason about for us.
WARD:
Yeah. It's just that sometimes it's scary, I mean recursion is scary for people, and things inside of things is scary for people [chuckles].
PATRICK:
Yeah [laughs].
WARD:
But I think I know what you mean. You sort of build up semantic units that represent what you're trying to accomplish, and then you build out of this Lego parts. You're building your Lego parts and then building new Legos out of the Lego parts and so forth. It's that kind of idea, right?
PATRICK:
Yeah. And the difference between my say like a Module Folder Structure and the Component Folder Structure is that the Component Folder Structure enforces restrictions on you that leads you down a better path in terms of avoiding unsaved [incomprehensible]. That's why it's best practice now to do that just because of that because the difference between the two is not much at all.
WARD:
So what's an anti-pattern that you would be steered around?
PATRICK:
Okay, so I guess let's give segue to data-binding or two-way data-binding. One of the biggest problems with Angular 1 developers today is that a lot of times, when people make the initial version of this page, they don't refactor it. And I say refactor as in if you make a large function, you usually refactor it to smaller functions so it's easier for you to reason about. The best example is Wizard or Form. You would make your form, maybe it's dynamic, you haven't do repeat in there, and you have multiple fields. A lot of people would use the primatives given for Angular and do click, etcetera. But no one actually refactors into Components so that way it's easier to reason about and you're able to have more control over the Performance and Logic. This is something that in any other framework like background for example, you would actually write everything manually. And because you're writing everything manually, you're more cognitive of the performance implications of everything as opposed to an Angular where you have so much power of everything. You're kind of drunk with it because you're constantly just using all the Directives in the world. And this is essentially scout master's talk about having to -- well, he's also about Performance and everyone using too much like ng everything. What I'm trying to get at is that you should refactor your behavior into your component so you could better optimize for it. That's the thing that kind of becomes apparent when you perforce into this component architecture because you're like forced to think of everything as a way to turn into a Component. And because of that, you're falling into dependent success there.
JOE:
I've got this image in my mind of Lukas ringing his hands and laughing demonically, whoah ah ah, as he codes up his Angular 1 apps and then being stripped of his power when Angular 2 comes around and like withering away and dying, aaahhh, the bucket of water thrown on him [laughs].
PATRICK:
Well, Angular 2, we do have ng-model backend in Angular 2. That's the most loved feature in Angular 1.
JOE:
Hey, that's a great segue! Let's talk about that. Go! [Laughs]
PATRICK:
Okay, yeah. Well, I talked a lot so I wanted to balance a bit. I don't know.
JOE:
No, let's talk. Your ng-model...
WARD:
Yeah, ng-model and...
JOE:
We didn't have it.
WARD:
And you were talking about two-way data-binding and anti-patterns. And you definitely had my attention since, I think, your two-way data-binding as a pro-pattern.
PATRICK:
Yes. I was kind of purposely segueing into this. Essentially, the reason why we want two-way databinding is for Performance. And that's because when we all went to [incomprehensible] world, we all found out that dealing with Forms is actually amazing. That's because it's a lot easier to reason about inputs with two-way data-binding. And the anti-pattern with two-way data-binding is that it's harder to separate concerns when dealing with data because, essentially, the model is updated in the UI, and this is more of I guess the answer to the previous question, the reason why ng-model is great because of that whole MVC architecture when you're making an ng-model and ng-form. So a lot of people -- I needed to do some back story -- essentially whenever it's Angular, no one, and whenever I ask Angular developers, no one really knows about the FormController or the ngModelController. Essentially, when you create a form, you're creating a Controller. And whenever you create an ng-model, it's essentially creating a Controller there and it's attaching it to it.
forms:
that's Template-Driven and Data-Driven. Template-Driven is marked up Directives and Components; Data-Driven is JavaScript Functions and Services. But essentially, with two-way data-binding, because you have this miniature MVC model going on in your forms, the two-way data-binding is creating the coupling for you, which is great and allows you to interact with your data that way and doing all the reason so there is no [incomprehensible], but essentially, it's an anti-pattern because two-way data-binding and other parts of your app can allow you to shoot yourself in the foot. That's why it's great for forms, if that makes sense.
WARD:
Maybe we can make it more concrete by doing an example. Let's suppose you have a lot of people, and they have a first name and a last name, and you want to construct a full name, you have a sort of computed full name property. So when I'm in a form and I'm updating a person, that's when the two-way data-binding comes to the form and I expect, for example, as I change the first name from Fred to Sam, the computed full name is updated for me dynamically as I go because the value of changing the first name goes into the object, the computed property gets calculated, and they [incomprehensible] of dirty checking, the computed property appears as I type.
That's the classic example of how you might wrap a concrete thing like person into a form. But now, I've got this long list of all the people that I know, the million people that are my best friends, and that's outside of the form and so... I know! Just take that as an example, then try and make the point that you were just making.
PATRICK:
In Angular 2, you're able to take advantage of actual computed properties. Angular 2 is like pushing most of the work into the language so that's just another example of that. But essentially, what you're running into is the data management problem and that is essentially like just a heart problem in general because if you're dealing with the form -- say you have a long list and say you have all these computer properties in everywhere -- essentially, you want to update that View Model then only when it's validated and it's ready, you want to update to actual Model in your Service or whatever just because you don't want to have any side effects happen.
WARD:
But I do want a side effect! I want if I change the first name, I want the full name to change, and there's nothing really complicated about this at all. This is one of the great things about Angular, it's that I don't have to think about it. I had a person and it has a first name and the last name and has one computed property, full name. Every time I change the first name or the last name, the full name is refreshed.
JOE:
No. Just as long as you didn't go levels deep on that.
WARD:
But I don't!
JOE:
Oh yeah, you really don't.
WARD:
Realistically, this is like falling off along. It was just a manufac. It was the first example that if you ever walked into Angular and you looked and they taught you something, this is practically the first example, and you said, "Yeah, give me some of that!" that's one of the things I really loved about Angular!. That's why I came to Angular! So if it's not that simple, then I feel like something has been taken away from me. And if somebody tells me that it was always so complicated, I'll look at them and I say, "What are you talking about? That wasn't complicated." But anti-pattern here, where is the anti-pattern? I'm trying to figure out why -- I'm hoping you can shed some light -where is the anti-pattern here?
PATRICK:
So you have two-way data-binding, I should just clear it out. You have that now with ng-bottle and you're able to do what you want to do. I'm really suggesting that, for a lot of other people, like it's a lot easier for them to shoot themselves in the foot because, for example, a good practice for creating a form is not to update the model directly because what if the user box out or what if the user disconnects or if they're all flying, etcetera, then you have this jailed data laying around. And if you update it automatically, you'd also have a multiple user concurrent problem as well.
WARD:
That's not solved by any change to data-binding at all. The full name is a display property. If I'm changing Fred and then the thing goes south or some other user somewhere else changed it to Rebecca, I got that problem no matter with or without regard to what data-binding system I have.
PATRICK:
I'm saying like you still have that; it's just in the language as a computed property. That's like a language user now.
WARD:
Well, we're going to have to dupe this up sometime. [Laughter]
JOE:
We're going to need to have a whole episode just about Angular 2 forms, just go through it.
WARD:
Because, I don't know about you guys, but I am freaking out by all this talk about how hard life has been for us and all the troubles we've been falling into. And I've got episode here saying, "Man, I've been cranking out some pretty mean apps and suddenly, they're telling me I've been doing it wrong all this time?" And instead, I got to stand on my head to scratch my ear, I don't get it. But there you go, that's another topic.
PATRICK:
Essentially, it's the whole Models to some going to Components to some, there's no difference. It's more of just for beginners. It's a lot easier for them not to shoot themselves in the foot.
I guess, two or more that directly addressed to that is, if you could change the Model on the Template itself, so that's a View, Change View the Model, that's data-binding. It's just more of like dealing with jailed data that people shoot themselves in the foot with.
JOE:
Alright, we are going to wrap up on that note. But I could tell that this is definitely one of those topics we're going to have to...
AARON:
Yeah, we're not going to agree on this anytime soon. I was lost and told so I was with Ward.
JOE:
This is a very interesting thing, and this is cool because I think we're representing a lot of people here in this conversation. So something will have to bring up in another episode. I'm sure, Ward, this is one of Ward's hot button. We can't even mention Angular 2 without this topic coming up, right, Ward?
WARD:
Yeah. I got a song and I've had about that. It's like an old soul song: [singing] If loving you is wrong, I don't want to be right... You know what I mean?
[Laughter]
JOE:
That's awesome.
WARD:
That's it, man. If shooting must open the foot, I'm going to keep shooting and I'm going to lose that foot.
JOE:
We're going to end this up. So, we're going to move on to picks. Let's have Aaron. Do you want to go first with your pick?
AARON:
Yeah! So anyone who knows me will know that the book Ready Player 1 was basically my favorite book I've ever read. Pick it up and read it. It's an awesome book. It's my favorite I've ever read. I've probably read it several times the last years. The author is releasing another book that will be a movie as well. It's called "Amarda", and it comes out next month, in July. But this week, he released on a blog that I will put on the show notes, Chapter 1 of his new book Amarda. And from the very first sentence, he sucks you in and it's a little last star fighter-ish, but I think [inaudible] why this guy, does a good name. So yeah, go check out this Chapter 1 of Amarda and I'm getting excited to get the book next month.
JOE:
Just to add, I've already pre-ordered that...
AARON:
Yeah, well, I've pre-ordered it as well so I'll have it delivered.
JOE:
Oh, nice.
AARON:
Yeah. Anyway, that's my pick.
JOE:
Okay. Awesome.
AARON:
Oh, can I have one more pick? One more pick?
JOE:
Yeah, go, Ron, go!
AARON:
I'm excited about the Mine Hive, the collection of awesome Angular people that are going be out in Boston later this year at "Angular Summit". So I wanted to just kind of throw it out there. Hey everyone, if you're East Coast and you want to get some Angular love, go check out Angular Summit, angularsummit.com and maybe submit a proposal speak as well as get a ticket. So yeah, that's my other pick.
JOE:
Sweet! Katya, you're up.
KATYA:
Okay, my pick for this week is "Sign Language" because I was learning that in school and it's such a cool language because you can communicate under water and over really, really big distances.
It's just really cool. I just really like sign language.
WARD:
Oh, great, Katya. Another way that two teams can talk to each other and I won't understand. [Laughter]
KATYA:
Exactly! [Laughter]
AARON:
That's why they made sign language, Ward.
JOE:
Yeah! That's really why.
WARD:
I knew it. I knew it. They're talking about me, too, while they're doing it.
JOE:
[Laughs]
KATYA:
Oh, you know. You know it.
JOE:
Alright. Ward, you're up.
WARD:
Well, first of all, "If Loving You Is wrong, I Don't Want To Be Right", I got the link in there, you got to have it.
JOE:
[Laughs]
WARD:
Secondly, there is still time for you to attend "AngularU" in San Francisco coming up June 22nd. All kinds of Angular team folks are going to be there, I'm going to be there, Joe's going to be there, lots of good people going to be there. So head on out to San Francisco and check it out.
And then, I picked up a book in the airport while flying back from Sweden. It's by a nobel prize winner named Daniel Kahneman called "Thinking Fast and Slow". Katya, you got to read this thing. It's so fascinating about the way in which he talks about how we reflectively behaves at ways there we're unaware of and think quickly to wrong conclusions and then how another part of our mind, which is the one we think is us, is occasionally engaged to correct those instinctive reactions and try and come out with reason to answers, and there's a sort of tension going on between this two parts of ourselves. The book is fascinating and it was the basis of his nobel prize in economics, but it's very readable. So, check it out -- Thinking Fast and Slow.
KATYA:
Now, I know what I'm going to read on the plane to Russia.
JOE:
[Chuckles] Awesome. Alright, I'll go and then we always like to have our guest go last so you'd be up to be, Patrick.
For my pick, I'm going to pick "Denmark". I just took a trip to Denmark for a week, had an awesome time, it was great, I spoke at a conference.
AARON:
Denmark!
JOE:
Even when I went to Sweden, I had no idea that if you're in Denmark, if you want to go to Sweden, you just hop on the train, no passports, no nothing, it was super cool. So I got to go over to Sweden for a day when around Copenhagen so lots of cool, very cool things, and just had a great time. So Denmark is going to be my pick.
WARD:
Was that last week you were in Sweden?
JOE:
Yes.
WARD:
I was there last week! How do we missed each other?
JOE:
I don't know! I was way down the South in Malmo and Lund in Sweden on Friday. Where were you on Friday?
WARD:
I was in Stockholm.
JOE:
Ah! Awesome. So that's my pick. It's Coppenhagen, Denmark, and by extension, Sweden. I had a great time in all those places. Fun place to go. Everybody speaks English. Super easy to go on vacation there. Loved it.
So Patrick, you're up!
PATRICK:
Yeah, my pick is "Angular 2". If you haven't already, go ahead and try it out. And, "Babel", that's my other pick. If you haven't ready, you should write something with Babel.
JOE:
Awesome. Okay, well, thank you so much for being on the show, Patrick. It was a really fun episode, I'll like this. This one's like this, this great. And good information in Angular 2 is coming up.
We need all these content as much as we can get it in the hands of the people. So power to the people, right?
PATRICK:
Right, yeah.
AARON:
The people have a right to know!
PATRICK:
[Chuckles]
JOE:
Yeah, I feel like I'm like a peerless winning journalist on the front lines of some war wearing a flag jacket.
KATYA:
Oh, yeah.
JOE:
Yeah, that's basically what I am!
KATYA:
Definitely.
JOE:
[Laughs]
AARON:
Dude, it's such a noble calling. Now, the podcast guy.
JOE:
Yes! [Laughs] It is noble! It is so noble [laughs].
KATYA:
And he's around herds...
JOE:
We all deserve...
AARON:
Nothing! We deserve nothing, bro.
[Laughter]
[Overlapping of talks]
WARD:
Really everybody is fishing for compliments now. This is tough.
KATYA:
You're fishing... You're fishing...
JOE:
Yeah. Anybody who agrees with me tweet one of us on the show today and let us know that you agree that this is a noble calling [laughs].
AARON:
If you agree with me that we deserve nothing, then tweet that as well.
KATYA:
[Laughs]
JOE:
Alright, tweet that. And if you agree with me that this is noble, we deserve adulation, tweet me.
KATYA:
Oh, totally.
AARON:
#noblepodcast
JOE:
Yup.
KATYA:
[Laughs]
JOE:
And if you agree with Ward, then tweet that, too, I want to hear that.
WARD:
Yeah, [incomprehensible] free people. [Laughter]
JOE:
Thank you everybody for listening in and we will see you all next week. Thanks, Patrick, again for coming, it's great episode. Talk to everybody later!
AARON:
Breeze!
[This episode is sponsored by Mad Glory. You’ve been building software for a long time and sometimes it gets a little overwhelming; work piles up, hiring sucks, and it's hard to get projects out the door. Check out Mad Glory. They are a small shop with experience shipping big products. They're smart, dedicated, will augment your team, and work as hard as you do. Find them online at madglory.com or on Twitter at @madglory.]
[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 wanna support the show? Now you can. Go to adventuresinangular.com/forum and sign up today!]