Angular transition to 2.0, part 1

BrieBug Solutions has created an online video series that provides information, tips, and insight on the transition from Angular 1.x to Angular 2.0. This video is a great resource for those in the industry who are interested in programming, typically programmers, to be aware of the Angular changes, as well as receptive to technology growth.

The videos are designed to convey a step by step tutorial with instructions on how to effectively transition between the two versions, and are explained by Angular expert and our CEO, Jesse Sanders.

Today we’re going to talk about transitioning to Angular 2.0. Part of this transition looks like we factor in our code into directive base components. Before we get to that though we’re gonna first start out with a base project. The project we’re going to base this off of is John Papa’s Hot Towel project and to speed things up we’re going to use his Hot Towel generator that uses yeoman to generate the project. You go to get John Papa, you can see he has several different repositories and one of them is the generator How Towel. This project here scroll down just a little bit it, has a couple of prerequisites, we need to have node installed, I’ll assume you already have that handled and then we need to go ahead and install a couple of items here, one of them being Yeoman. In my case, I already have Yeoman installed so l’m going to check to see if there’s an update.

There are some instructions on how to not require Sudo, if you have not already done this, if you’ve not already looked at it how to do this, I strongly recommended it. It makes the npm Global installs a lot easier to work with. In this case here Yeomen is already done, and now we’re going to install a couple of the other dependencies as well. We’re going to install Bower and install Node.

The next step is installing the Hot Towel generator itself. With Yeomen you can generate templates, so we’ll pull in John Papa’s Hot Towel generator, install that. We’re gonna need a directory to create it in so wherever we actually put this generator that’s where it’s going to generate our code into. I’m going to create a project called Hot Towel, go to that directory, and now I’m going to run Yeomen, then tell it the name of the template, HotTowel. The first Hot Towel is the name of the template, and the second Hot Towel is the name of the project. As you can see, Yeo Hot Towel and then the name of the app.

While that’s running, let’s talk about some things that the Hot Towel project provides. The Hot Towel project uses Gulp extensively, It gives you a lot of features that you’re going to want right away. You can run unit tests running using `gulp test` which gives you the output of what the status on the tests. You can run `gulp serve-specs`, to run in the server with the HTML file that is generated, and that’s another way you can run the test.

You can run your project in dev mode, `gulp serve-dev`. This will update the browser with any file changes. Instead of having to constantly refresh your browser, it will do that for you. If you have not used browser sync before, I recommend you look that up and see what features it offers. It looks like it’s done generating, the npm install failed, so we’re going to run it again, and see if it will resolve this time.

We can build the project, this is an optimized build so it will take and combine all the CSS into a an application and library version of CSS and JavaScript and will place these into the build folder. We can also run this optimized code using `gulp serve-build` and we can run our optimized code in the browser and be able to see how that works. The structure for this project is pretty simple, everything is contained within source (src). Inside of source is a client folder and with that is the content.

Installing packages – what we’re doing right now, the MPN install has additional features to it, where when you run it, as soon as it’s done it will go ahead and run Bower install. It also uses Wire Depp and that’s used to automatically inject your dependencies into your indexed HTML, this makes it simple so you no longer have to maintain that.

The modules have an app level module, app admin which has core and widgets, dashboard, layout, widgets, core itself and it’s dependencies, the main thing to understand with the modules is that because it’s modular based we can add and remove modules just by requiring them in based on other modules and that allows us to bring features in and out of the application without having to remove them from the loaded source code. There are also a couple of block modules here, they are reusable blocks of code, that can be used across projects by including them as dependencies.

There are a lot of different commands here including bumping versions which will help you manage your versions.

We still have a problem here on the bower install, so we’re going to go ahead and load the project. My preference is to use webstorm, use whatever tool you want. As you can see, here is our source, here is our node modules, we’re going to run Bower install since that did not complete. It looks like we’re still having problems, we’re going to use Webstorm to see if we get a better result. Excellent, it looks like we’re past the issue and we’ve loaded our Bower components.

Let’s go ahead and run our project. We have our project, it’s up and running, the pages are pretty simple, we have four components here, all of them are hard coded. We’ve got an admin page, not really doing much of anything, we’ll use this project here as a starting point. We’ve talked about some of the great features, including browser sync, which I want to show you here – I’m going to pull up Safari, I’m going to use localhost:3000, it’s also responsive, it stacked that gracefully. I’m going to switch to admin in my Chrome browser, it made that change on Safari, that’s part of browser sync, it syncs between many browsers and allows you to test quickly on how things look and some of that functionality.

What’s not great about this project? I think the great things outweigh what isn’t great, when we dig into the client folder here, we’ve got apps, images, styles, test helpers, index HTML, I don’t have to go in and maintain this list or bower libraries. It has a great build routine, it creates optimized code, what we found though is primarily controllers and views. We have a controller, that isn’t very big and doesn’t have much functionality, it’s based on the controller view paradigm it has quite a bit to it, instead of being thin or lightweight. None of the code is reusable, everything that is contained in dashboard stays in dashboard, we can’t replicate it into another project or page, it would be nice to pull the people grid and place it on another page.

The containers all basically do the same thing, but are repeated functionality that isn’t reusable at this point. The folder structure has blocks, core, layout, widgets, and then we’ve got dashboard and admin, so inside of our app we have our feature pages, admin and dashboard, in an app this small it’s not really a big deal, two or four pages is fine, but if we had fifty pages we’d be cluttering our app folder and it would be very difficult to find things, especially if we start doing reusable components it would become a mess. We want to reorganize this a bit. When we look at the data, we are making calls to get the data directly instead of using a route resolve.

We do like how modular this is. We have our dashboard controller, we have the spec that goes with it, here’s the test, here’s all of the HTML necessary for dashboard, here’s the module that declares the dashboard, here’s our route for dashboard, each feature page has it’s own route to find in its own module, it indicates where we’re going to get the HTML from, we’re going to use the dashboard controller and we’re going to use the controller ask syntax and that helps us get away from scope. We don’t see a resolve that will allow us to inject our data directly into the dashboard controller. Our data loads with this are fast, using a resolve could potentially help us speed up our process. In our next video, we’re going to refactor this code, we’re going to move admin and the dashboard into a features folder, we’re going to create our first component based directive.

To share these videos and access the secrets to transitioning from one JS Software to another, visit the blog section of our company website. These 6 videos will be released in chronological order and will be posted to our blog site on a weekly basis.

Please enjoy, learn, subscribe, and like our channel on YouTube.

Find us on YouTube by searching for “BrieBug”.

BrieBug Solutions a Denver based website and mobile application development agency that specializes in Angular and Full Stack development. If this is a technology that you would be interested in to boost your business, feel free to contact us so we can get you started on your vision!

  • Contact Us
  • Telephone: 888.679.2201
  • Address:
    BrieBug |
    12596 W Bayaud Ave Suite 201 | Lakewood, CO 80228