--- title: Component Pattern --- Writing modular and DRY^[[Wikipedia - Don't repeat yourself](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)] code is a good habit. It will keep your software maintanable, help with testing and produce parts that can be reused throughout your software. One paradigm to achieve all of this is the *component pattern*. The underlying idea is to encapsulate your code into isolated components and thereby having small building blocks which can be composed to build a full application. Seperating code into components is nothing new. There is a whole branch of software engineering, called "component-based software engineering"^[[Wikipedia - Component-based software engineering](https://en.wikipedia.org/wiki/Component-based_software_engineering)], which emphasises the use of components to preserve seperation of concerns.The UML specification for components reads as follows:^[[OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2](http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF)] > A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. > > A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a type whose conformance is defined by these provided and required interfaces. With the rise of React^[[React - Thinking in React](http://facebook.github.io/react/docs/thinking-in-react.html)] and the introduction of Web Components^[[W3C - Introduction to Web Components](http://www.w3.org/TR/components-intro/)] the pattern has gained a lot of momentum and is currently seen as best practice for building large JavaScript applications. Angular 2 will also rely heavily on components,^[[Ionic - Angular 2 Series: Components](http://blog.ionic.io/angular-2-series-components/)] so the emphasis on components will not only help structuring our app, but will also make it easier to migrate to Angular 2 once it is ready. If you translate the concept of components to Angular 1.x, they are really just directives with an isolated scope, a controller and most of the time they also have a template. Communication between components is handle with attribute bindings (`=`, `&` and `@`) and `require` property of the directive definition object. A future Angular release will include a `angular.component` helper, which will by default create directives that `bindToController` so that we do not have to write the directive definition boilerplate all the time.^[[Github PR - `angular.component`](https://github.com/angular/angular.js/pull/12166)] ## Container Components Jason Bonta gave an excellent talk in which he shows how to further improve the application architecture by distinguishing between *components* and *containers*.^[[React.js Conf 2015 - Making your app fast with high-performance components](https://www.youtube.com/watch?v=KYzlpRvWZ6c&feature=youtu.be&t=22m23s)] Essentially, containers are fetching data from the server or any other remote service. The reponse data is then passed to its (child-)components, which will process the data and render markup. Components are completly data-agnostic. All of their input will be obtained through a parent container. While the talk is about React the concept can also be applied to Angular. Imagine an app, named *whiz*, that lets users assemble their own squad of Marvel characters. It has a search field to query Marvel's developer API for characters. Every character whose name matches the search term will be displayed inside a list. Listed characters can be selected and added to the user's squad. Squads are stored into `localStorage`. Users can name their squad and remove selected characters. The app can be split into two parts. One is concerned with searching charactes via the Marvel API, displaying the results and letting users add characters to their squad. The other displays selected characters, allows to give the squad a name and remove characters from the list. The corresponding mockup looks like this: ![Image](/assets/whiz-mock.png) ```html ``` ```html ``` --- ## Directive Types -> goes hand in hand with not using `ng-controller` and `ng-include`. ### Container - API calls - Interaction handler - maintains model ### Section - Break applications in smaller parts - not-resusable - DSL -> describes our Components in our application (example no
-soup -> ProductView ...) - less lines of code and complexity - A Page can be constructed out of several sections that describe the Page. ### Widget - super small - rusable - only have ONE purpose --- https://en.wikipedia.org/wiki/Component-based_software_engineering https://medium.com/@learnreact/container-components-c0e67432e005 http://busypeoples.github.io/post/thinking-in-components-angular-js/ http://jaysoo.ca/2015/03/30/container-component-pattern-in-angular-1/ http://nicholasboll.com/articles/angular-component-composition-part-1/ angular.component - https://github.com/angular/angular.js/issues/10007 - https://github.com/angular/angular.js/pull/12166