[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.
