Current approaches in componentization and reusability on the web frontend have some undesirable side effects. This video shows the user what the potential problems are and how modern methodologies such as WebComponents and Angular aim at tackling them.
- [Juri] In the previous video, we learned about our project setup, about ES6, and some tooling. In this video, we are going to take a look at some shortcomings of current componentization approaches, and then we will learn about WebComponents spec and how it aims at tackling those issues, and finally, how Angular 2 fits into this picture. When we use jQuery, or a jQuery based framework, we usually have an approach like this. We define an HTML element, and we want to make it reusable, so we want to encapsulate the behavior. As you can see, I've already imported jQuery here in our example, and what we are going to do now, is to create a jQuery plugin.
The simplest way of doing this is as follows. We define a helloWorld plugin. We have iterate over all elements where we instantiate our plugin, and then finally, we append here our DOM element. We can also pass in some options here to our plugin, and try then down into our HTML, and close the HTML text. This is our jQuery component code, or plugin code, as they are often called. To instantiate it, we actually have to use what is called now, a so-called selector.
We use an ID here. We call it hello world component. Now obviously, we also need to mark our HTML DOM element with that ID. Finally, we can invoke our plugin using the name and passing in the options who world. If we want an example now, we see it gets printed on our page, just as expected. This works very well, and our component is very portable. However, it has a flaw. It doesn't represent true encapsulation.
Let's define a style tag, and on our strong tags, we set of font size of, let's say 35 pixels. If we save it now, we see how the style goes into our component, and this is something we would like to avoid, especially if we port this component to other applications. Another problem is that it doesn't carry well the semantic meaning, like we define here an ID, and we give it a name hello world component, but for others, it might be a bit obscure what our component's actually doing.
Now, there is a spec called the WebComponents spec, which aims at avoiding these side effects, and implement the components in the right way, so on the w3 org website, there is a WebComponents wiki. As we can see, a web component is structured into three different components: the Shadow DOM, the Custom Elements, and HTML imports. There are different implementations available. On the webcomponents.org site, for instance, you can find a lot of articles and polyfills that describe how to implement WebComponents in today's browsers.
I actually found a very simple one, so let's go and install it. By using bower, we an install it, using the hello-world-element name, and download it to our project, and if we now switch over to our IDE, we see we got the bower_components, and the webcomponentsjs folder, which is actually the library for running WebComponents, and here is our simple helloWorld element WebComponent example. To run it, we need to import two kind of fonts.
First of all, the library for running our WebComponents, and then the hello world HTML. Let's give it a look, as it is quite an interesting import. As you can see, we have a template up here, which is actually the rendered DOM of our component, and here below is the implementation, which uses the current web component API to create the element, but what we are really interested in is how we use our component in the HTML. What is nice, is that we can actually define a custom element called hello-world, and then pass the name who as an attribute to that element.
This keeps a very nice semantic meaning. Now, if we fire up our live server, we can actually run an example in our browser, and see how it nicely renders. What is most interesting is when we inspect our component in the Chrome Developers Tools, you can see there a note called shadow-root, which seems to be special, and indeed it is. It is the representation of the so-called Shadow DOM. This kind of DOM can be in closed or open mode, and by default it is closed, meaning that it gives true isolation to our component.
We can quickly demonstrate this by, again, adding our style with a font size of 14 pixels. If we now save it, and refresh it in our browser, we see that nothing happens. As you can see, although the styles get correctly loaded by our browser, they don't leak into our component, which gives us a very nice isolated behavior. Now, the WebComponents spec is still a work in draft. Browser support is growing, but not yet here. Meanwhile, there are a lot of libraries implementing this kind of component-oriented approach of designing web applications.
So does Angular. Actually, since Angular 1.0, you were able to define custom elements like this hello-world tag, but it didn't give us that nice isolated behavior, as in WebComponents. In Angular 2, components get even more sophisticated. A typical app consists of a component tree. Like in this blog post from Victor Savkin, a core member of the Google Angular 2 team, we see such a structure. We have a to do app, which is nothing else like, a top component, and nested todo components.
Each component gets a nice isolated behavior, just what we would expect from a pure web component. Also, the data flows in a top-down manner, from the top component, over properties, into the todo components. This was the last video of Section One. What we learned is about current componentization apporaches, about the WebComponents spec, and we also quickly showed how Angular 2 fits into this picture. We also learned about TypeScript tooling and ES6 features, and we also had a look at our Angular 2 project setup.
In the next section, we finally get a first grasp of the new Angular 2.0. See you there!
Get up to speed with one of the most important building blocks of Angular 2: component-based directives, aka components. Components are reusable HTML widgets that replace the controller-based architecture in Angular. This course guides you through the various steps in migrating to Angular 2 and building real-world Angular components of your own.
Author Juri Strumpflohner starts by setting up a modern development environment with TypeScript and ES2015 support. Next, he explains what components are, how to build them, and how they differ from directives. He provides an opportunity to apply these new concepts while building a fictitious dashboard application for a home automation system.
Next, learn about HTML rendering templates, see how to establish a data flow between different components, and even find out how to integrate external libraries. Juri also shows how to make components production-ready and maintainable by applying automated unit and end-to-end testing techniques. As a bonus, discover how to bring your Angular 2 components to other environments such as the server side and mobile devices.
- Upgrading to Angular 2
- Feeding a component with data
- Building a foundation for your Angular app
- Building reusable models
- Comparing components and directives
- Integrating an external library
- Bundling and minification
- Maintaining components
- Testing and debugging Angular 2 components
- Building hybrid mobile apps with Angular 2 and Iconic 2