Charles: Hey everybody. Welcome to episode 123 of the Adventures in Angular Show. This week on our panel we have, Joe Eames.
Joe: Hey everybody.
Charles: Lucas Ruebbelke.
Charles: John Papa.
Charles: Ward Bell.
Charles: We have a new panelist and that’s Alyssa Nickel.
Alyssa: Hey. Hey.
Charles: Do you want to introduce yourself really quickly?
Alyssa: Yeah. I am a web developer in Angular lever from Orlando, Florida.
Charles: Very cool.
Joe: You’re in Orlando?
Alyssa: I am. It’s amazing here. You all should move.
Charles: Hey it’s snowed here.
Joe: We aren’t allowed to have two panelist from the same geographical region of the country. Are we?
Alyssa: Who else is here?
Charles Does that mean you’re going to quit or am I Joe?
Lucas: John is from Orlando.
Joe: He loves wearing hats with ears so much. He moved to the official city of it.
Alyssa: I was going to say, I think John’s more from Disney, right? Not really Orlando. I don’t know. Maybe you actually live here and do the community.
Charles: Is that a different country?
Alyssa: Yeah. It is.
Charles: Like Vatican City. You live close enough to the park.
Ward: I live in the Star Wars area of the city actually.
Lucas: Oh my gosh. I would move there in an instant. Oh-oh. We mentioned it. We broke the rule.
Alyssa: What was the rule?
John: No Star Wars.
Alyssa: No Star Wars. Sorry.
John: We break it every show.
Ward: They get along like Trump and Hillary do. Also, let’s not talk about politics.
Charles: Alright. I’m Charles Max Wood from Devchat.tv. Quick announcement that JS remote conf call for proposals and tickets are available. Go check it out. We have a special guest this week and that is Victor Savkin.
Charles: Victor, I’m pretty sure we’ve had you on the show before but do you want to give us a brief introduction anyway. Let us know what you’re up to?
Victor: Sure. I’m Victor and I work on Angular Core. At some point I do with the change of action a few others more doing it with Angular 2 and currently I’m mostly working on the router.
Charles: Awesome. When we booked you we were going to talk about the router but we screwed up when we talked about the router last week. You also seem to be quite the expert on Migrating Angular 1 Apps to Angular 2 and that does involve the router. We figured we just dig right into that. Now, some of us are lucky, we get a right just Angular 2 apps, it seems like there are quite a few apps out there that have grown rather large in either 1. How do you migrate that stuff? How do you move one to the other? Because if it’s a big system, it’s not like you can just snap your fingers and say, “Oh, Angular 2. Here we go.”
Victor: Yup. We would like to have that. Just a snap and it’s on Angular 2. Unfortunately this is not the case. You need to put some effort to move your Angular 1 Apps to Angular 2. When you’re on a team that’s going to be a problem when building Angular 2, that’s why on the team we put together a few libraries to make this migration easier and make this migration gradual, meaning you can do module by module and component by component. What we did is we built two libraries, the first one is NgUpgrade which allows you to run your Angular applications in the hybrid mode. We use both, Angular 1 and Angular 2. The second library is a special mode for the router. If you’re using new Angular 2 router, you can easily migrate your Angular 1 apps to Angular 2.
I can talk about each of this a little bit. NgUpgrade is a special library we built that allows you to bootstrap your Angular 1, existing Angular 1 application that you have inside an Angular 2 shell, like an Angular 2 application. Basically what happens is you have one application that uses both the frameworks and its bootstrap in such a way that both the framework can see each other. What I mean by that is that if you have an Angular 1 provider, an Angular 1 service, it can see Angular 2 services or Angular 2 providers and if you have an Angular 2 provider, it can see Angular 1 providers. That’s one.
The second thing that the library does is, it allows you to mix and match Angular 1 and Angular 2 component. If you have an Angular 2 component, you can downgrade it to Angular 1 and then that component can be used inside your Angular 1 code in such a way as if it was written in Angular 1. Similarly, if you have an Angular 1 component, you can upgrade it to Angular 2 and then this component can be used inside your Angular 2 code, in such a way if it was written in Angular 2. Basically, NgUpgrade what you can do is you can bootstrap you app, your providers can see each other, your Angular 1, Angular 2 providers. You can freely interleave your Angular 1 and Angular 2 components. You can mix and match. That’s one part of the story, the NgUpgrade library. It’s very useful. We use it internally at Google a lot.
The second part of the story is migrating the router. Why is the router special? Why can’t we just use NgUpgrade networks? It is special because the router is one of very few things that you use that use global mutable state. In general, the moment you start dealing with global mutable state like it’s kind of difficult, and this global mutable state is your location. The browser has only one location bar and it’s mutable, if you have an Angular 1 router in your Angular 1 app, touching that location bar, changing it. You cannot have another router, touching it or changing it without being aware of the Angular 1 router. Because if you do that, you have two objects independently modifying that global mutable state and suddenly you have a lot concurrency related issues. It’s very hard to deal with, very hard to understand.
What we did regarding the router, we build a special way to configure the router and tell it, don’t worry about this router, those held by Angular 1, or by an existing app, just don’t worry about those. Only worry about this routers, these are your routers. It allows you to partition the set of routers that you have into two buckets. The first bucket is the Angular 1 bucket, your existing application is handling and the second one is your new behavior that you migrate to Angular 2. That makes sense?
Joe: Yes. It’s just basically two routers working side by side?
Victor: Correct. Basically it allows for the two routers to coexist on the same page. Touch the location, modify the location, listen to it without stepping to teach other’s toes.
Joe: Can you make them step into each other’s toes?
Victor: You can, if you don’t configure the Angular 2 routers. If you don’t tell that router what’s behind of Angular 1, it will try to do crazy stuff in your location. You’ll be confused, happy, depressed, you know, life is bad.
Joe: Is this some matter of just basically making the Angular 2 router work in such a state that you can say hey, don’t handle this types of routes?
Victor: Yes, exactly. Usually, it’s basically like a few lines of configuration where you can say hey, do not handle all the router that start with flash setting or whatever. And suddenly all the routers start with flash settings, won’t be handled by the Angular 2 router and will only be handled by the Angular 1 router.
Joe: What about vice versa? Will the Angular 1 router still try to handle all the routes? Even the ones Angular 2 wants to handle?
Victor: We didn’t change the Angular 1 router even though we could because we have the power. You could do it because regarding to Angular 1 router the reason is you work around that allows you to achieve that without actually changing the library itself.
John: Because as I recall Victor, we know what router we’re going to use in Angular 2 but there are variety of the routers available for Angular 1 apps. And you can’t go around modifying all of them.
Victor: Exactly. What we try to do…
Joe: Why not? Let’s just go around and modify them all.
Victor: In general. It’s not like we actually consider it. There are two main ways to migrate your application. And the two ways are, [00:15:35] or incremental. And one of the basically says, “Hey, let’s just take our Angular 1 router and all the configuration we wrote for the Angular 1 router. And let’s [00:15:47] the implementation. Let’s just say we will do this with probably different way, we’re going to [00:15:49] the implementation and we’re going to replace the Angular 1 implementation in the router with an Angular 2 router.” The API will look the same, Angular 1-ish, like it looks right now. But the implementation is different. That’s an alternative approach. When you solve an implementation you slowly define a transition, your route from Angular 1 to Angular 2.
The second approach is incremental approach when you say, “Hey, we’re not going to slow point [00:16:15], if it’s Angular 1 it remains Angular 1, just pure Angular 1.” We are going to take chance of your application. Maybe module by module, chunk by chunk can migrate those chance to Angular 2. We thought about it really hard. We actually attempted to do the first approach but it turns out it’s sort of easier using the incremental approach for the following reason: once you start pretending that you have the new router that has the Angular 1 shell or Angular 1 module. Once you start doing it, you complicate the mental model of the user or the developer because now when I Angular 1 code, I don’t really know if I’m actually using Angular 1 or Angular 2. If it’s Angular 2 under the hood is slightly different because it will be slightly different. It complicates the mental model a lot. What we decided to do instead is just say, “Hey, we want to keep the boundaries of Angular 1 and Angular 2 as explicit as possible. If you have a chunk of code written on Angular 1, use just Angular 1. Once you transition to Angular 2, use just Angular 2. And then we allow you to express its boundary.
Joe: I don’t think that totally answered a question that I have about what if I’m using the UI router.
Victor: If you’re using the UI router or any other router that you want to use. Who knows what you’re doing but let’s say the UI router. The UI router actually supports its own way of migrating apps on Angular 1 to Angular.2 so if you want to stick with the UI router, you’re on luck. You’re in good shape.
Joe: Wait, you mean if I want to keep the UI router even when I’m in Angular 2, when I have my app fully covered of Angular 2 [00:18:02]
Victor: Yup. You can do that. They actually support Angular 2. They’re doing great work. If you actually use it as your preference and if it works for you, that’s great. Just stick with that. But if you want the transition from the old router to the new router or from the UI router to the new Angular 2 router then you should [00:18:20]. You can still do it. The reason is Angular 2 router doesn’t make a lot of assumptions at Angular 1 router. The helper function have that allows you to set it up in such a way that it works, it may be like 10 lines of code. You can write a similar one for the UI router and my assumption would be that it shouldn’t be very difficult to do.
John: That makes total sense. And we’ve always said, that the official Angular 2 router was we’re going to do our best to make it a great router but we never thought that it will the only router in the world. We figured people, that’s why it’s a separate module and people would make their own choices.
Victor: Exactly. It’s a separate module an even more so this module make zero assumptions or zero private APIs. Means that if you want to have your own implementation as a router you can do it. We are not special in any way. We just use the public API of Angular Core.
Ward: Victor, with this in mind. What does this tells us about, if I’m looking at big Angular 1 code base, what should my game plan be? What should my strategy be? Assuming it’s got routes and assuming that those routes are factored into separate work flows so that there are some seams in the application. How would you look at Angular 1 app and start drawing on the board your plan of attack?
Victor: Alright. Cool. I actually wrote a blog post about it. After the podcast, if you are interested you can go and check it out. With writer boots internally at Google., the process we try to follow and some of these steps are very simple and automatic and some of them require more work. Let me outline the steps. The first step that you want to do is we want to use NgUpgrade and the upgrade module that that library provides to wrap your Angular 1 application into an Angular 2 shell. We want to bootstrap your app with NgUpgrade essentially.
Alyssa: Before you do that though, is there any baseline that you have to get to? Or do you think that any Angular 1 app in the world could be ready for this step?
Victor: It’s hard to say any because there are so many different ways to do up in Angular 1 application and so many different kind of a lot of ways to match your infrastructure. I would imagine most of the application should be ready. At least internally, the applications we have Ad Google. We don’t have any problems with wrapping those into the shell.
Alyssa: Okay. Cool.
Victor: We do that [00:20:54] and actually talk more about each of the steps. I just want to mention all the steps so we know how the process goes.
Lucas: It used to be true that you can’t use NgUpgrade with 1.2 or previous. Is that still true?
Victor: I believe to use NgUpgrade fully, at least NgUpgrade study can use this 1.5 as far as I remember.
Alyssa: I think that would be a good base line then to say that you have it, we speed to 1.5.
Victor: You need to use fairly modern version of Angular 1. Like 1.5 or 1.6.
Joe: It used to be NgUpgrade work with 1.3. I personally tested that myself. It depends on what features you’re using, I assume. Has that changed? Or you talk about like to fully know that you’re going to be good?
Victor: I actually do not know exactly. Am I understand you that we tested 1.5. It may work with 1.5 but Ad Google have applications using 1.5 so we guaranteed it works with 1.5.
Joe: Okay. Gotcha.
Victor: It may work with other versions in Angular.
Ward: I did have one more question about the router. Just really quickly, the new Ng2 router, current Ng2 router versus UI router, it used to definitely be the Angular 1 router is missing a lot of features that UI router was providing. Feature that a lot of people wanted, that’s one reason UI router became just popular.
Ward: Is that still true? Or is there a lot more feature parody now?
Victor: I think that is a lot more feature parody. Obviously, the router had previously wasn’t capable enough to implement all the scenarios like Ng router, the Angular 1 router. The Angular 2 router, the new official router is a lot more capable and mostly [00:22:50] the design from Ngrx/router. Ngrx/router is another router created by external contributors and then we merged it to efforts. We had our own router as it fills Angular 2 router had an Ngrx/router and at some point we decided there are too many routers. When you have your routers, it’s too confusing. We merged a bunch of the routers into one, which is the [00:23:14], the one that we support, the Angular 2 router. I think it’s more or less on far with the UI router. It becomes more of a preference of what kind of API you prefer. If you are the more of reactive style of programming, you may want to use our official router. But if you’re already the UI router and it works for you, keep using it, it’s great, I like it, it’s totally fine.
Ward: I call yours the victory router because of Victor. Sorry about that.
Ward: What about NgUpgrade? NgUpgrade changed recently.
Victor: Let me explain why NgUpgrade changed. In general, the way we build software here on the Core team, is that we try to release some sort of version which is kind of ready, put it out there during the bit of experimentation phase to get the feedback. To get the feedback from the community to know we can arrive at something that is usable. We did that multiple times. We did that with forms for example. The first version of forms we put out didn’t have a [00:24:19]. A lot of drama and now it has [00:24:24]
Ward: You’re damn straight it was Victor. A lot like cats and dogs about that one.
Victor: I think overall. Like this is a good strategy. You put something out there, you iterate quickly based on the feedback and a few months of maybe it takes longer, you are right but sometimes it’s very usable. It’s actually pleasant to use and it’s capable to express in a lot of scenario. We did the same with a lot of router until we arrive at this one.
NgUpgrade, it’s basically the same story. We put NgUpgrade, the original version like a long time ago just to get the feedback and show that it’s possible to run that application in this hybrid mode and how components can interact and what not. We got the feedback, like a lot of feedback and we have a lot of issues with the original version. For example, [00:25:19] it was kind of not very good and the main issue that it didn’t with the AOT compiler and it happens if you write an Angular 2 application, most likely you want to use AOT compiler. We got all these feedback, but because we got this feedback slightly too late, the filer was already out, we couldn’t just upgrade a router. Angular fresh upgrade stays. There you could use it, that’s why we introduced a new version of upgrades which is Angular/upgrade/static which is when hen it comes to mental models, it’s very similar, it provides the same set of capabilities and just the API is slightly friendlier and it allows you to run your hybrid back in the AOG mode which makes it smaller and faster and whatnot.
John: That last word is static, Angular upgrade static. Where did you come up with name like that, static?
Victor: Naming is hard. What we try to emphasize I guess is that static mean that you can run it and you can analyze it statically without actually running your application. The first version of upgrade, use the whole of reflection to hook things up and if you want to use AOG compiler, that’s not allowed.
John: We sidetracked you but Joe asked, there’s two versions, the other’s the static one, that’s the one people really should use if they’re starting today.
Victor: If they’re starting today, migrating the Angular 1 to Angular 2 they should use the static, the new version. But if you already used the original version they can use it, hopefully at some point. You should switch to the static one. And in our experience is that it’s not so hard to switch because mental models are very, very similar.
Lucas: We got this new Angular static and now you’re talking about the five steps and then we sent you off of the space. Bring us back to the five steps.
Victor: Okay. The steps, the first step we want to bootstrap our app inside in Angular 2 shell. The second step is that we want to go through every Angular 1 module we have and add an engine module, the Angular 2 model to be explored, every module that point to become both Angular 1 and Angular 2. Step three is the longest one, the hardest one is actually migrating your components and services from Angular 1 to Angular 2.
Joe: Hold on. Hold on. We got to go back a step. Why should I turn all my Angular 1 modules in the Angular 2 modules? [00:28:08]. I am an outspoken critic of modules in Angular 1.
John: It’s taking Joe hard because. The guy went mad and told everybody that you should only ever have one module through every Angular 1 module and now you’re told.
Victor: Why you have to do it, you don’t have to do it. At first it’s very [00:28:32]. The first two steps, step one and step two, like bootstrapping them and adding the modules, are mechanical steps. It’s also the same for all applications and those take 20 minutes or whatever because there is no creative work in [00:28:46]. Those should always work. You should be able to do those in like 20 minutes.
And why you want to do those like wrap and stock into shell and end Angular 2 modules, next to your Angular 1 modules to set up the skeleton. Once you have the skeleton in place, it doesn’t matter what you want to migrate, a service or component you always have a place where you can register a component or service. You always have a place with the component, sort of the migrate one, the Angular 2, 1 left. I just find it personally easier to think about my application knowing that no matter what I pick, no matter which area I decide to migrate to Angular 2, I always come at place with that thing left because I know it when I’m when I’m saying that to do it one module at a time. In reality, maybe you want to do it in a slightly more chaotic way. I just like the structure is in place, but you have to do it this way. If you want to do it like super strictly one module at a time and edit it on module only to the module you’re migrating currently, you can do it. It’s fine.
Lucas: What if you’re really like chaos and you’re like Joe? And you have just one big Ng1 module, can you create one big Angular 2 module and then start putting it together?
Victor: Yeah. You can do that.
Lucas: Joe’s still in the game.
Victor: I guess what I’m saying is that you don’t have to follow the steps exactly for your whole application. You can follow the smaller scans. I’m going to make read this section, and then you set up a skeleton for that section and you migrate that section first. For me, it’s easier to think about it. I know, no matter what I decide to migrate there is always a place, there is enough infrastructure in place. I can do it without thinking about it. Does makes sense?
Lucas: That makes sense. We’re on step three still?
Victor: Let’s go to step three.
Lucas: Let’s see if we can get to step four.
Victor: Step three is interesting.
Joe: Hold on. I’m going to back you up for a second. Just the way you can talk a lot. Several steps, let’s just review. What is the step one and two for everybody who might be [00:30:56]
Victor: Step one, wrap your Angular 1 app in an Angular 2 shell. Super easy, it takes 20 minutes automatic application independent. It should be the same regardless of the aptitude. More relax. Maybe you have a [00:31:10] with that but overall it should be the same.
Joe: That’s pretty easy to do.
Victor: Step 2 is basically if you start to create a module, like a bunch of modules, you add an Ng module next to Angular 1 module that you migrated, you migrate an Angular 1 module, you’re going to add an Ng module in that next to it probably the similar kind of name and then you’re going to import that Ng module into the root component of your Angular 2 shell, the root module of your Angular 2 shell.
Joe: So basically you wrap it, wrap the application which easy and then [00:31:45] Angular 1 module, create an Angular 2 Ng module and then import it to my Angular 2’s root.
Victor: Step three is where it gets slightly harder. It’s actually migrating your services and components from Angular 1 to Angular 2. Migrating services, it’s usually straight forward, because those do not depend on another Angular APIs. If you want to migrate an Angular 1 to Angular 2 because your ejector can see each other as I mentioned at the beginning of the podcast, you can take one service with a bunch of decorators and it should just work. It becomes an Angular 2 service, and Angular 2 provider.
Migrating components from Angular 1 to Angular 2 or directives from Angular 1 to Angular 2, it’s kind of tricky. The reason why it’s tricky because APIs of Angular 1 and Angular 2 are just different. What we find is the result is usually better, once you migrate the component, like you have less code, less hacky, it’s more maintainable but it’s not mechanical work. You actually have to understand the two frameworks and you actually have to sit down and derive your component, you factor a component into an Angular 2 component. The BSNI, the BS is my [00:33:08] we gave a talk at Angular connect I think last year, some time ago about how to migrate non trivial large Angular 1 to Angular 2 and the result of that migration is better. You have way smaller code and faster, better in all sorts of ways. If you’re curious about how to do that, you can look up that talk onwards.
Alright, this is the most important step. This is where all works ends. What you usually do and what we recommend is for you to go to Ng module and find a leave component, component that doesn’t depend on another component and migrate that component shells. Because once you start some leaves, you can work your way up to the root.
Joe: Just a recap. Leave component used to actually be a physical thing that one for we’re discussing the router, we’re going to be components and leave components and all that. Can you just recap what are leave components is for everybody.
Victor: When I say leave component I just mean a component that doesn’t depend on other component. Like when you have an input, an input would be a leave component. It’s sort of composite about the component. Like simple low level component. Of you start migrating those it’s easy because they are usually self-contained. Once you migrate a bunch of those you can start migrating composite components. Components that depends on leave components. And eventually, if you keep doing it the whole module will migrate from Angular 1 to Angular 2. But you don’t have to actually start with leave components, just easier if you think about it this way. You can mix match components in any way. We recommend it because it’s easier mental model wise. You’re starting from this point downstream everything at Angular 2, but if you go up it’s doing good. That makes sense?
Joe: It does. And Victor, what happen if like the existing application you have is using the [00:35:01], the #routing and you want the new Angular to use #routing. Can you mix and match or how does that work?
Victor: You want to use #router for both or only to Angular 1 part?
Joe: Imagine if I wanted to use the same for both be fine, but what If I have existing Angular 1 app that’s using #routing? But in the Angular 2 stuff, I want to start getting over to [00:35:23] routes without the #? Can I do that?
Victor: We actually didn’t try it but in theory you should be able to do that because Angular 2 supports a special way to, it can be at Angular 2 router. Can be configured in such a way that you can split the URL into two part. The Angular 1 part, that part of Angular 1 and the Angular 2 part which is kind of Angular 2. In theory, you could say, hey I’m going to take your version after the # and just ignore it when it comes to Angular 2. The Angular 2 will just use the basic part, and the Angular 1 will just use the # part.
John: I’m just thinking there’s a lot of code bases out there where people are using Angular 1 with # still because maybe they still have [00:36:01] at the time. Heaven forbid. Maybe they want to start moving over now, now they the app they can’t use their existing codebase. It’s good to know.
Victor: Yup. Alright. Should I keep going with the steps?
John: Yes. It’s a three-step program so far. How many steps are there?
Victor: Five steps. There are five steps.
Victor: Basically, after step three what we have is all the components, al the service particular module are moved to Angular 2, are moved from Angular 1 to Angular 2. Step four is dividing all the routes. Taking those routes for that module and moving those to the Angular 2 router. Basically, it’s what I talked about at the beginning of the podcast. For small projects you can take all the routers and migrate those at once. If you have a large app like there’s 100 of routes it’s very difficult to do it at once so we renew router. You can do it sort of module by module, chunk by chunk. The way you can imagine it is the way you start your app, you have two sets. And one set, it’s full browse the second set is empty. The second set is the Angular 2 set and the first set is the Angular 1 set.
While performing the maker, if you’re going to take route into first set and move those to Angular 2, basically move it from the Angular 1 router to the Angular 2 router.
John: Hold on, question. Are you saying you should be doing this while you’re doing your migration? While you’re migrating the services [00:37:36] are waiting until you’re done migrating this components and then start migrating your routes?
Victor: Wait until you’re done migrating all the sources and components of the particular module. And I’ll say if you migrate a chunk of those. You can migrate the routes because the way you can think about it is, the router feeds a couple of your components. You have your components and they do stuff and then the router allows you to instantiate your component. So it’s easier to talk about it if you know that all of the components that you need to instantiate from the Angular 2 site are already Angular 2 components. The Angular 2 router will only instantiate Angular 2 components. Once you’re done migrating the bunch of components from Angular 1 to Angular 2, you can migrate all the route that instantiate those components from the Angular 1 router to the Angular 2 router.
Joe: Does it only have to be the top level component? That has to be an Angular 2 component in order to migrate the route? Say that I’ve got a parent component and child component. I’ll migrate the parent component to Angular 2, can I then switch the route.
Victor: I can. You totally can.
Joe: I can. But you’re saying you don’t necessarily recommend that. You’re saying you recommend migrate both the parent and the child to Angular 2 and then switch the route.
Victor: Yes, exactly. Let me clarify that what we provide, the Angular core team is a bunch of mechanisms and you can use those in any way you want. There are a lot of developers that use different background, different preferences and a lot of different organization and your organization to process is different for some organizational rhythms. It’s totally fine. You don’t even have to migrate the following component to switch your route. You can do basically whatever you want. The mechanisms are flexible, but on top of those mechanisms we provide a sort of conventions or the process that we think works really well. What I’m talking about right now is the process, you can do almost whatever you want if you desire so but if you follow our process, the proof I’m trying to describe is that you will find some documentation, some example apps that show you different steps of this process. It’s easier to follow the process unless you actually have the reason not.
Lucas: Are we on step four still?
Victor: Yeah, step four. Basically at the end of step four, what you have is an Angular 1 module that was fully migrated to Angular 2. All the components and sources are already Angular 2 services and components. All the route are Angular 2 routes. Step four fully encapsulates all the working guide in a particular module. You do all the steps, three and four for every module in your application and at some point you arrive at state where every single module of your application has been moved to Angular 1 to Angular 2. And at that point you can execute the five which is the mechanical step.
And step five means basically you go, you remove Angular 1 from your setup, you remove NgUpgrade, you simplify your bootstrap because you don’t have to bootstrap Angular 1 anymore and you have a pure Angular 2 application, fully migrated from Angular 1.
Just to summarize a few important things to say is that this migration can take a long time and it can take weeks or months, depending on the size of the application. Because it can take month, we have an important goal when designing this tools and the process and the goal was that we should treat this migration as a large scale refactoring and not an [00:41:13]. When you treat a large scale refactoring and the tools allow you to do that, you can always implement new features or fix bugs while migrating. At no point your application the state where you cannot deploy, you should be able to keep working on your application, implement new features and whatnot while migrating.
John: Yeah. I’ve always felt that you should assess your app at the beginning and think about how long this is going to take because if it’s going to be less than three months, don’t play this game just re-implement. Is my instinct and I’m curious about your answer to that but if it’s going to be more than three and then you realize you can’t just stop the show and you’re going to have to do a progressive migration. I don’t know what happens in those three months or no you should only do a complete.
Lucas: Some people have budget to go down that road either like a large company. They may have a limited time frame, it might be three days to them.
John: Maybe they’re number is three days. If it’s just three days or less I would just completely re-implement it but if it’s more that I got to go through this five step process.
John: You have a feel for that?
Victor: I agree. It depends on your organization. If you are going to write your app anyway, sure you can just ignore the upgrade process and do it from scratch. But I think the process even though it sounds like there are five steps like oh, it’s a lot of steps but three out of five steps are mechanical steps that all together take an hour. Only step three and four create a step. But that work you would do even if you start from scratch, because you would have to write those components anyways. It still works and disappears if you start from scratch.
I would say unless you have a very small application, that it takes a week for you to write try to follow the upgrade process. I think the new version of NgUpgrade, upgrade static fix a lot of issues people have with the original version. You can actually see errors. It’s useable. It’s not super hard to use and I would recommend just trying it. I don’t think it’s very difficult and the reason at this point is enough documentation online so you can figure it out.
Ward: That may have shifted the balance for it because the first one I think is sufficiently hard and there were enough places to get lost that you needed a big project to justify it. But it sounds to me that you smoothed it enough that the decision point, you could decide to do this with a smaller app than I had virtually thought. That’s good news.
Joe: There is one other reason to consider rewriting versus migration that is to do some kind of come clean up but that’s gain only works if your app is on the smaller side and smaller set of features because one of the problems we certainly have with applications is you end up with features you don’t know exist. You got code but you’re not 100% sure what it does. If you don’t migrate it slowly and you try to rewrite it you might have trouble replicating the features that actually exist.
I got a couple of prediction about upgrades in general that I think I would love to hear any validation from people’s experiences over the next years. One of which is that there will be many, many applications that will be running Angular 1 and Angular 2 forever. I believe that that’s going to be very true.
Victor: I actually think it’s fine. The one of few downsides, for me is that you have to ship both Angular 1 and Angular 2 like bite size wise. You actually have to distribute, ship the framework but apart from that, I think it’s totally fine. And if you have a large chunk of your app that doesn’t change very much, performs okay and [00:45:15] Angular 1, just fine. Leave it then, just fine.
Joe: Right. The other prediction that I have is there are going to be a plenty of people out there who are going to one night or maybe over weekend, go out Angular 2 with their app without telling anyone. All of a sudden they start writing Angular 2 and tell their developers hey, we could write Angular 2, don’t tell the management. I know that’s going to happen.
Victor: I hope so. I hope at some point I would build setup, build back that stuff and it would be smooth enough that you can do it quickly.
Joe: It is certainly true that that first two steps, like you said they’re so quick you can stay late one night for an hour or two and all of sudden have Angular 2 in your app. I talk a lot about migration, the couple of question that I get very, very frequently. I like to ask you those questions. The first one is, performance, and I know what I tell people but I want to hear what you say. What are the performance applications of taking Angular 1 app and putting Angular 2?
Victor: First two, it doesn’t affect in the performance of your Angular 1 app. It performs the same way that part of your application or that application still around with Angular 1. It should be fine. If you migrate one component from Angular 1 to Angular 2, that component is run by Angular 2. It becomes faster. If you migrate a large table, it’s performance critical from Angular 1to Angular 2 and just use that table in your Angular 1 app, that table would be faster. Should detection I would be faster, a lot of things will be faster. In general, performance should get better. Angular 2 in general should be faster once you start moving component to Angular 1 to Angular 2 the performance should increase. The only caveat is that you need to ship both the framework, Angular 1, Angular 2. The payload may actually increase.
Joe: That’s where I want to stop you. We talked performance. Can you qualify what you mean by performance?
Victor: Sure. What I mean for performance is, I got two aspects. The first one is the payload let’s say the size. The second one is how fast we can instantiate vies and components and how fast we can run change detection. While doing the migration most likely your payload would be bigger because you need to ship at least a chunk of Angular 2. We try to instantiate that in a way but you know. We still need to ship some code. The payload during the aggression can get a little bit bigger. The second part of the performance which is how fast we can instantiate the views and how fast we can run change detection is better in Angular 2. Angular 2 is way more efficient at doing those things. Those things like view instantiation and change detection will become faster once you start migrating from Angular 1 to Angular 2.
Joe: Now it’s true, that with the migration path while writing NgUpgrade. Every time I change detection cycle is occurs in Angular 1, that triggers the change in section cycle in Angular 2 and vice versa, right?
Victor: Let me a little bit be more careful. Once those triggers that detection for the whole thing. Basically the two change detection always run together. At no point you should run only one but not the other one.
Joe: If you’re writing two changes sections cycle at the same time can that be a performance [00:48:36] sort of performance there?
Victor: No. The number of runs will be the same. You run two change detection systems but the amount of work is still the same. If you imagine a giant table that is no longer go on but Angular 2, the Angular 1 change detection system you don’t have to worry about that table. It’s handled in Angular 2. The amount of work doesn’t increase by your migrating, the number of runs shouldn’t increase. But you run two detection systems. But I don’t think this should be a performance.
Lucas: Let me give you a couple of scenarios and see if you have any thoughts on this. One is, I’ve migrated 95% of my application to Angular 2, all I have is maybe one component, one directive in Angular 1 on a couple of services. But I’m still running that Angular 1 change detection cycle. What’s the performance between that and when I finally kick over and get rid of Angular 1 completely. Is this noticeable?
Victor: Let’s assume the device percentage that you didn’t migrate, like it’s 5% on the change detection work, 5% of all the bindings in the system because you can’t have one more component that’s used everywhere. And then it matters. But let’s say it’s 5% of the work.
Then if you get rid of Angular 1, you won’t feel that much because it was only 5% of the work. What you would face is the payload. The payload will get more way smaller because you don’t have to ship Angular 1 to the client.
Joe: Could I have some pieces of my Angular 1, say that I’ve migrated 95% but I’ve got some pieces of my Angular 1 app that change the text that really heavy and slow. If I’m looking at an Angular 2 like component has nothing to do with that. Will that slow anything down?
Victor: No. It won’t. The two systems run together but those are two separate system. Meaning that, imagine the whole world in one part. Having the giant piece of pie that is in Angular 1 part of pie and it’s very slow. But you have that sort of thing that two part of pie. You just have to do a part of the same pie. The Angular 1 change detection doesn’t affect the Angular 2 change detection system and the Angular 2 change detection system doesn’t affect the performance of the Angular 1 change detection system. Those are separate.
Ward: There is an implication here which is if you have a place in Angular 1app that is particularly slow, that would be the place where I would start with my migration. That would be a good reason to start there, you might have better reason to pick something else but that would be a mark in favor of doing that one early.
Victor: Yeah. That is true. You should example the gigantic table. The gigantic table we have thousands of roads and it doesn’t perform an Angular 1. You can migrate that table to Angular 2 and to be faster because the change detection system is faster in general or the view instantiation is the fastest, so the table will become faster. And also you have more control over how change detection runs in the Angular 2, even if it wasn’t fast enough even then, you have instruments or mechanism to make it faster now.
Joe: Final scenario related to performance. I’ve got a component that I migrate to Angular 2 it has a child component still Angular 1. And that has some slow binding in there or something. How does that affect performance?
Victor: The bindings in the Angular 2 part will be faster and then when you start there to check in your Angular 1 component, the child, that would be flow. Once again, it’s how we compose components, it doesn’t matter. They can be siblings or parent and child, it shouldn’t matter. The amount of time you have to spend running change detection like bolt the systems together and combine, both will be the same. All like roughly the same.
Lucas: One other question I have related to Joe’s scenario is if I have a parent I that’s Angular 2 component and it has a child that is an Angular 1 component. Can it still have a time compiling and all of the fancy jazz to make it all work?
Victor: You can. The say it works is as follows. It works. Otherwise it would be very unfortunate. You can do the fancy jazz every single work. The only thing is that you have to ship, we won’t be able to appreciate any part of your Angular 1 code and we cannot appreciate your Angular 1 framework. You’d have to ship your whole Angular 1 framework that you do right now and you have to ship to the client the Angular 1 component with all of code. It may have in bad code, we cannot reshape that. Because we don’t know what do your Angular 1 part does. But yes, in the Angular 2 part or the application will be appreciate in a way, whatever is not used for better shaking away. You can do it. The answer is yes.
Joe: Right. So I got another question that people frequently asked me. I want to ask. On the appointment, I just added the Angular 2 to my application, I already got my deployment path for Angular 1, it’s already set up and all of sudden now how do I handle the fact that I got Angular 2 involved in things to pick my after production?
Victor: This is a very nuance question. And there isn’t is I looked the deployment options you have. I do it when I put together example app and whatnot. It’s just bundle every snap into one bundle, like the Angular 1 and Angular 2 and all the core of the application into one bundle. But you don’t have to do it like this way. You can have Angular 1 separately, the separate file that you ship with Angular 1 partly are separate and the Angular 2 parts, the framework itself and all your app can be bundled into one bundle like over a multiple bundles. It really depends how your do it process is structure to it.
Joe: Right. If you’re doing modification and that’s entirely different between Angular 1 and Angular 2 because Angular 1 has sort of special modifier.
Victor: Angular 2 have to have this magical AOT compiler. You have to run Angular 2 if you want to be efficient, you have to run your AOG compiler against your code base. And the it’s up to you, do you want to bundle Angular 1 together with the result of that run or you want to keep your Angular 1 stuff separate.
Joe: Could you theoretically do two bundles like one for your Angular 1 and one for your Angular 2?
Victor: Yeah. You should be able to.
Joe: I guess it really just depends on what makes sense for your specific scenario.
Victor: Yup, exactly. Basically it depends on your setup. If you have some sort of system jazz, you can do whatever. The system is very flexible, gazillion bundles in all that somehow hooked up that everyone see everything. If you use web pack, again, you have a lot of options about how you create bundles so the Angular 2 part and Angular 1 and whatnot.
Joe: Next question. Can you integrate or utilize the Angular to CLI when using NgUpgrade?
Victor: I actually do not know. CLI is great, I use it from time to time but I haven’t tried it with NgUpgrade.
Joe: I can report having just saying this question appear in the channel recently that that is not a primary scenario for the CLI at this time and it’s not clear that you could use the CLI and to a hybrid app and you should be prepared to not be able to use the CLI for hybrid app.
John: Seems like it’s a lot of work to try to get those two to work together.
Joe: Yeah. And it’s not the prime scenario for CLI. CLI is really about how do I develop efficiently green field.
John: Right. Cool. I think those settles my questions.
Joe: Victor, there’s some changes coming in your life. Can you tell us about them? I don’t mean all of them, I don’t want to know your dark secrets. We just want to know your open secrets.
Victor: Alright. Sure. I actually have some exciting news I’d like to share and that Jeff Cross who works at me on Angular core and I. I just left Google to start our own company, Narwhal Technologies. What we want to do is we want to help organization that are in need of sort of high quality, in depth Angular guidance and support. If you are thinking about migrating your Angular 1 app to Angular 2 or just adopt in Angular 2, we can help you by providing general guidance, doing architecture of use in solving difficult issues and setting up your upgrade story. If you have high value projects, you don’t want to [00:59:25], you want to execute it efficiently I think we can do valuable for you and your organization.
Since Jeff and I have been on the Angular core team for many years, we understand that you are working in the frameworks or both, Angular 1, Angular 2 either well. We have a lot of experience in helping our Google customers, internal customers to be successful in Angular in general and Angular 2 in particular. That’s why I believe we can actually provide a lot of value to your organization. If you’re interested, you can check out our website and there will be a link in the show notes, I think. Let us know what you think.
Charles: And the name of your organization again is Narwhal, like the whale with the unicorn?
Victor: Narwhal Technologies. Like a unicorn of the sea.
Ward: That’s the best name for a company I’ve ever heard.
Lucas: Doesn’t it need some like modifier before Narwhal?
Charles: Like the release name for the…
Victor: We actually thought about, okay this is [01:00:30] we thought about weird names for companies.
John: Like can we hear the weird ones?
Victor: This is not the weird ones. We had lots of ideas. Culineminers. If you’re trapped, we can help you whatever, but we decided to go.
Charles: What was that one where the Argentine team crash on the mountains and they ate each other?
Victor: Something like that. We decided not to do that. To go with something that is…
Joe: I’m surprised you didn’t name it something like The Silence of the Lambs.
Victor: I watched the movie when I was a teen. I really want to cook. Because he cooks, the main character Anthony Hopkins, he cooks. That guy is awesome, he’s slightly weird, he’s good spoken.
Joe: Slightly weird.
Victor: That is why I’m cooking. Since then I’ve been cooking my whole life.
Alyssa: Oh my goodness.
Victor: Just watching The Silence of the Lambs. I’m vegetarian. Just to be clear.
Lucas: I’m never eating a meal that you cook.
John: He’s vegetarian but that doesn’t necessarily mean what he serves you.That’s really awesome and congratulations on that, Victor.
Alyssa: Yeah. Congrats, Victor.
John: I’m excited to see you Victor and say, hello Victor.
Joe: Hey Victor. Don’t you have some even more exciting news that you want to announce?
Victor: Of course I do. Jeff Cross and I are going to do one of the [01:05:10] in training at the Ng Conf and the topic of our training is deploying Angular 2 apps to production.
Charles: Let’s go ahead and get to picks. John, do you want to start us off with picks?
John: I’d love to. I just can’t wait. There’s a movie that Ward and I are going to go see in about a week and a half.
Lucas: Pencil sharpening 3.
John: I have reserved. Back to back seatings, all day long for four episodes in arrow. So we can sit through row one Star Wars. Because I know we can’t wait to see how this one turns out. I think it has something to do with the dead star but I’m not sure.
Alyssa: Does that mean that Ward is coming to Orlando? Should I be in on this action?
John: You could join us, that’d be great. Ward’ss coming down to Orlando, I think next week. Oh my gosh. It’s creeping up on me. By the time this thing airs.
Charles: He’s going to watch his pencil sharpening video and then sharpens some pencils. John [01:06:30] in the theater.
Ward: Exactly. We’re going to bring our pencils and we’re going to sharpen.
John: Actually the reason words coming down here is we’re going to be filling some play down place for [01:06:39] site, where we’re going to do a couple of different videos where one of them is we’re going to go through creating Angular 2 apps together and see what happens and then the other one is going to be more of a tutorial kind of thing of we code along with you, the audience. It’s a new format that we’re trying out and we conform to see how this turns out with me and Ward if you watch the video of me and Ward, you know that it’s never normal. Half the time we have no idea where we’re going. It’s a lot of fun and it’s going to be like duet, it’s never really very planned which is a lot of fun too. Joe and I have a second pick together, don’t we Joe?
Joe: Yes we do.
John: Do you want to announce it?
Joe: Sure, I’ll announce it. John and I and Daniel Lane have done, we just went to Tampa, Florida and did an Angular 2 training class and it went so well that three of us decided hey, what can we better than see each other’s faces even more? So we are going to be going around the country doing Angular 2 training classes. We try to do one every couple of months, our next one is going to be in [01:07:53], probably towards the end of February. If you wish to come or are looking for that, stay tuned, follow us on twitter. We’ll be making some announcements and putting up places we can pick up tickets and check out our training. Come and learn more Angular 2.
Alyssa: Do you have a show name or something? Like The travelling Angular 2 band.
Joe: Close. Talk Coders.
Alyssa: Oh my goodness. This is great.
Joe: Little bit of [01:08:21] take to top gear.
John: Exactly. We’re trying to [01:08:25] that out.
Joe: [01:08:25] top gun and I thought you’re all [01:08:27] we’re going to sing the righteous brothers song. We lost that loving feeling.
Lucas: We’re going to have John with his shirt off, playing volleyball on the beach.
John: Does that make Dan iceman?
Joe: I’ll be goose.
Charles: I’m going to take advantage to that segway. Joe do you have any other picks?
Joe: Yeah. I’m definitely going to pick this new Star Wars movie. I got to do it Ward. I’m so sorry.
Ward: You guys are killing me.
Joe: I went and bought tickets the minute they went on sale and had to search all over the valley to find a theater that had the seating at the time that I wanted to go. Because it’s just really popular and I heard that they actually crashed Fandango because everybody’s trying to buy tickets all at the same time.
Alyssa: Oh my goodness that’s wonderful.
Joe: I thought that was one of those rushing hacker plots.
Charles: They keep making money, they keep making movies, sounds good to me.
Joe: I’m also going to pick Ng Conference just had another planning meeting today about it. There’s some really awesome stuff we gotten to works especially on Saturdays so you have to be coming. Be sure to keep your Saturday open because we’re going to do some really cool stuff on Saturday.
Joe: Yow. Those are my picks.
Charles: Alright Lucas, what are your picks?
Lucas: I have two quick picks this week. One is a Chrome plug in called Toby which allows to put a new tab, it sets some kind of this way to manage existing tabs a lot of times we have like 10 tabs open because I need to keep track of them. It kind of actually group them together in kind of this Toby tab of questions. Here’s a shopping list, check this things out later, here’s things I need to follow up and then here’s things I just want to keep on speed dial. Really super helpful Chrome plug in, that’s Toby.
And my other pick is after years of seeing this thing evolve, [01:10:31] actually launched the new year of [01:10:33]. [01:10:35] with a little fanfare but he actually just won an award for that and it looks really super cool, have tons of great characters which is famous for and having on [01:10:46] authority that is going to start pumping out new content for the blog so that is my second pick.
Charles: Awesome. Ward, what are your picks?
Ward: It’s Black Friday, it’s kind of the season Thanksgiving’s over and it’s time to start thinking about what we’re going to give to our friends for Christmas. Given that I just learned that Victor learned about cooking, discovered he wanted to be a cook as a result of watching Silence of the Lambs, for him there’s this lovely movie called The Cook, the Thief, His Wife and Her Lover and if you read the plot of that you all know why that fits. But I’m also been doing some other shopping and I thought I would share with you some of things that I think might be up there, ready to go like a bacon ornament. I think nothing looks better on the tree than a bacon ornament. There is a lovely turkey mask, kind of looks like John from behind.
John: What do you mean I’m out of his head.
Victor: I just know that John’s behind at all.
Ward: That came out. For Chuck there’s the Santakini.
John: Hold on. How do you know what my behind looks like?
Lucas: Play by play.
Ward: We realize that we have to honor some of those other religious traditions so there’s this singing Jesus wallet that sings songs when you open it. I think that’s got to be good to somebody. For those of us who are on the other side of that fans there’s the Moses action figure and nothing would be complete without a Star Wars 18oz. Yoda mug. There you have it, that’s my shopping list at the end of 2016.
Charles: Alright. Alyssa, what are your picks?
Alyssa: I got invited to speak at an amazing conference, I don’t know if you guys have heard about it. It’s going to be on a boat. It’s called the Ng Cruise and I’m really, really pumped about it. It’s, “Oh yeah we got some people cheering on May 29th in 2017.” My talk is on Animations, CSS animations in an Angular world and I was just actually just down like a week and a half ago, talking to Matias about some super stuff he’s got coming and what he wants me to showcase in that. So I’m really, really pumped for that cruise.
My other pick would be I got invited recently to do some stuff on Egghead and so they’ve got some awesome just like whole upgrade talk just reminded of some cool Angular things I’ve seen on there. So if you need a quick tutorial or something, jump on Egghead. Yeah. Those are my picks.
Lucas: Awesome. Would you like a ship sound to play when somebody mentions Ng Cruise?
Charles: I need to get the sound board together. Alright, I’m going to jump in with a few picks really quickly. First of all, a Chrome plugin that I’m going to pick as well and what it is, is if I go to facebook.com, unlike you, I see my menu on the left just like you do, I see you pages and all that crap on the right side just like you do and then for my feed I see whether you think you can or you think you can’t, you’re right, Henry Ford. Newsfeed eradicator and that’s my whole feed it actually gets rid of your feed on Facebook which is super nice and keeps me distracted by at night. I love it. That’s a news feed eradicator plugin for Chrome and I really, really like it.
I also picked up a couple of Amazon Echo Dot because we have an Amazon Echo and we liked it. I’m putting those in a few rooms on my house and really enjoying that, been playing with IFTTT and a few other systems. Just to see what I could make it do. Yeah. Those are my picks.
Victor, what are your picks?
Victor: Alright. Here are my pick. This year I discovered Philosophy. I didn’t discover Philosophy, I started reading the Philosophy. And there are a lot of books and one of the books I like the most, probably easiest one to read was the book by Peter Singer called Ethics in the Real World and the collection of essays on all sorts of things. If you like to think about like what’s wrong, what’s right, how to live your life, you should check out the book.
Charles: Alright. Cool. Remind us really quickly how to find you, now that you’re not at Google.
Victor: Okay. You can find me if you go to nrwl.io which is our site, the site of our company. You can also find me on Twitter if you go to twitter.com/victorsavkin or you can find me if you go to vsavkin.com
Charles: Very cool. Alright, we’ll go ahead and wrap up the show. We’ll catch you all next week.