Do you want to write powerful, maintainable, and testable front end applications faster and with less code? Then consider joining this course to gain skills in one of the most popular Single Page Application (SPA) frameworks today, AngularJS. Developed and backed by Google, AngularJS is a very marketable skill to acquire.
In this course, we will explore the core design of AngularJS 1.x (latest version of AngularJS 1), its components and code organization techniques. We will enhance the functionality of our web app by utilizing dependency injection to reuse existing services as well as write our own. We will create reusable HTML components that take advantage of AngularJS data binding as well as extend HTML syntax with a very powerful feature of AngularJS called directives. We’ll set up routing so our SPA can have multiple views. We will also learn how to unit test our functionality. At the end of this course, you will build a fully functional, well organized and tested web application using AngularJS and deploy it to the cloud.

PB

First of all I want to thank the author of this course in investing his time sharing knowledges about this JS framework. The course helped me to better understand the mechanism of Angular framework.

DR

Sep 18, 2016

Filled StarFilled StarFilled StarFilled StarFilled Star

This is an excellent course. The lectures are clear and very well-prepared. The course material is excellent and Yaakov is an excellent presenter: very informative and engaging. Highly recommended.

From the lesson

Module 4 - Components, Events, Modules, and Routing

In this module, we start by introducing the idea of Component-based architecture. We will then delve into the AngularJS component API. The component API is something that was just recently added into Angular 1 and it's not only supposed to improve your application through the use of Component-based architecture, but also prepare you for an upgrade to Angular version 2, which uses components almost exclusively. We will then learn about the AngularJS event system and how to split up our application into smaller modules that can then be glued together to produce our final application. We'll finish off the module by diving fairly deep into Routing between views in your application and, specifically, into the use of the ui-router module, which is one of the most popular open source routing solutions within the AngularJS ecosystem. In fact, it's so popular that even the main Google documentation for routing in Angular links to ui-router. Routing is a very important topic. Without it, your Single Page Application is stuck displaying just 1 view, without an elegant way to display other views.

Taught By

Yaakov Chaikin

Adjunct Professor, Graduate Computer Science

Transcript

[SOUND] Angular 1.5 introduced a new way of implementing directives, components. A component is a special kind of directive that uses a simplified configuration that assumes some defaults which are best practices anyway. While components don't restrict you to component based architecture, using components makes it easier and more natural to structure your application code that way. Writing your application using components also brings you closer to the style of programming that angular version two uses. First, let's go over the principles of component based architecture and how it expresses itself through angular components. The first principle is, is that components only control their own view and data. They never modify data or DOM outside of their own scope. Because of prototypal inheritance, it's possible for your code to modify data pretty much anywhere in your application. While that can seem like a really convenient thing at times, it very quickly leads to chaos as no piece of your code in your application can be assured that it's data is safe from side effects it knows nothing about and it doesn't even control. This is the reason why angular components always use isolate scope. The second principle is the components have well-defined public API. That is data inputs into the component and data outputs from the component. In order to carry out this principle, to be true to the component based architecture, component code should follow some simple conventions. These conventions are designed to further discourage manipulation of data that doesn't directly belong to the component, which can happen even with isolate scope. For example, if you pass a value using the equals sign by directional binding, any changes you make to the data in the component will reflect in the parent as well. That's why the inputs so to speak, into the component should be defined only with one way binding and dump attribute value binding. Even with one directional binding, if the bound value is an object, changing that object's property values will impact that object outside of the component. This is simply because objects in JavaScript are passed by reference, and while you're not modifying the actual reference to the object, you would be modifying the value attached to that reference. And that's why another convention is for you to never change the property value of a passed in object or an array. And that's why we really said the words well-defined API. APIs are contracts. You expect to give a certain input, and you expect to receive a certain output. In the case of component based architecture, if I am a user of a component with an API, I have to give the API certain data, be guaranteed that my data is safe from being modified, and then expect the API to produce some defined output. The output of the component is defined with a ampersand as callbacks to the component events. The data is passed back to the caller through the key value map object that maps the caller's argument name with a key in the map. We have seen this before with directives. Another principle is that components have well-defined lifecycle. That means they have a number of pre-defined methods that we can tap into at different times of the life cycle of the component. One of the methods is $onInit. That method is used for you to initialize things for your controller's functionality. Another method is called $onChanges that gets a change object passed into it, and that method is called whenever one-way bindings are updated. The change object itself has a current value and a previous value among other things. And you're able to see how the value changed and respond accordingly. Yet another method is called $postLink, and that method is very similar to the link method we had in the directive. Another method is called $onDestroy, and that method is called when scope is about to be destroyed, meaning when it's getting unloaded from memory. You can use this hook to release external resources, watches, and event handlers that were set up in the other methods. There are a couple more methods that I'm not showing in this list. So feel free to go online and look at the documentation for the component API life cycle methods. Another principle in the component-based architecture is that application is really should be viewed as a tree of components. So that means that the entire application should be comprised of components. And as we said, each one would have a well-defined input and output. With the two-way data binding minimized, it's easier to predict when and where the data changes. So you could be confident what the state of your component is. So let's go over the steps in creating a component in angular. As promised it's even simpler than a directive. Step 1 is to register the component with the module. You will notice that the format is very, very similar. The first thing you do is you give it the name of your component. And that's the normalized form which means, in this case, myComponent in HTML will be seen as my-component. However, instead of providing a function or factory function as the implementation of your component, you provide a simple object. In this case, it's a simple object literal. This is the typical configuration object. It just has properties and values those properties, that's it. The next step, obviously, is to configure the actual component. One of the most common properties of a component is template or template URL. This is because most components have a template that is associated with them. You're not required to provide a controller for the component. You only specify one here if you actually have some functionality to it. Otherwise, angular will provide an empty object automatically, and will also automatically place the instance of this component onto the isolate scope with the label of $ctrl. Speaking of scope, you don't see it defined here at all. That's because in a component, the scope is always isolate with no ability for us to change it. Instead, we have a property called bindings. Bindings object is the isolate scope parameter mapping definition. It's actually exactly the same thing used before, but the property name before used to be scope and now it's bindings because we are assuming isolate scope all the time. In our component template, we'll use the properties that were passed into the component. Note that we're using the angular automatically generated label $ctrl which refers to the controller configured for the component. In the HTML that uses the component, in this case, my-component, it's used as exactly as you would use the custom directives that we've quoted before. Again, note that the camel case naming of the tag name and the attribute name declared in the bindings should now convert into all lowercase with a dash in between. In part two of this lecture, we're going to go to the code editor and see these concepts in action.

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.

Coursera provides universal access to the world’s best education, partnering with top universities and organizations to offer courses online.