2.2 Configurable Properties
In the last lesson we saw that the
restrict property is not supported when using Angular components. There are other configuration properties that are also not supported in components. In this lesson, I'll review which properties are supported in components and which are not.
1.Introduction2 lessons, 06:28
2.Creating Your First Component3 lessons, 19:33
3.Working With Components3 lessons, 20:40
4.Conclusion1 lesson, 00:58
2.2 Configurable Properties
Hi, folks. In this lesson, we're going to review the configurable properties that we can use in our component definition. As we saw in the last lesson, the restrict property isn't supported. First of all, let's take a look at the other properties that are no longer supported. One property no longer supported is the replace property. When using a component, the rendered content including transcluded content will always be wrapped in a custom element. The replace property, which although it still works in angular1.x is actually deprecated in any case to two inherent problems in the feature, they can easily be fixed. Another property that is simply no longer required is the priority property. Components are always single elements. This is also why the multiElement and terminal properties aren't supported, as well. Components always have an isolate scope. So the scope property isn't supported, either. And as there is a new way to bind attributes to a controller, the bindToController property is also unavailable with components. Lastly, the templateNamespace property is no longer supported, because custom HTML elements are always HTML elements. In addition to these properties, there are also no compile or link functions and it's for this reason that is not recommended to convert directives that do a lot of DOM manipulation or add DOM event handlers into components. So, these are the things we can't do with components. All other directive properties, including controller, controller as, require, template, template URL and transglued can all be used in the same way as they are with directives. There is also a new property not available with regular directives, the bindings property, which is the replacement for bindToController. With the bindings property, we can bind attributes to the component's controller. We could make use of this property for our modal component. Let's say, we wanted to be able to optionally add a title to the modal component. We could do this using a simple attribute on the modal element in app/app.html, the main file for the application. Let's just open this app So, down at the bottom of the page is a custom modal element. Let's add a new attribute, so that we can parse a title into our component. We need to make sure that we use hyphens in the attribute name and we can optionally use a data prefix. So now in the component file, we can add a bindings object. And we want to add a binding for our modalTitle attribute. So this time, we use camel case for the attribute name instead of kebab-case or hyphen case. We specify how the binding should occur using the value. In this case, we can use an at binding, because the actually be binding to you is a string. The question mark is to mark the property as optional. The bindings property let us specify the inputs for our component and as well as the at binding, we can also specify a one way binding using the less than character. Before our new binding will work, however, we need to have a controller for our component to manage the component scope and allow it to work with bindings in the template. We can add the controller and controller as properties to our component, and we'll do that after the template URL property. The controller, as property is used to namespace the bindings in the template. It's a best practice to use this, as it removes ambiguity in the template by making it explicit where a particular binding value is coming from. The controller only needs to be an empty function at this point. We can now update the template to make use of the new property that may be added to the components controller in modal.html. And let's add this outside of the form The if directive and binding both use the modal namespace, which makes it clear that this property is coming from the modal controller and let's just view the app in our browser now. So as you can see, the test title that we added to the custom modal element in app.html has pulled through into our modem template. So in this lesson, we looked at the configuration properties that we can use when creating an angular component. We saw that a number of properties we can use with directives are now deprecated in components. These are the bindToController, multiElement, priority, restrict, scope, templateNamespace and terminal properties. We also learned that we don't get compile or link functions, either. We then moved on to look at the new bindings property, which allows us to map attributes from the component element to the controller. We use this to allow the example modal to have a title separate. We also added a controller and updated the template to use the controller, as binding format. Thanks for watching.