Tuesday, 11 October 2016

As I do a deep dive into Angular 2 I've been finding some amazing features, one which really stands out being the Decorator ContentChildren. ContentChildren allows a component to access it's children components which are placed between it's selector. An example of such a setup is as follows:

<parent>
<child></child>
<child></child>
</parent>

now inside of the parent's component it can define the following:

@ContentChildren(ChildComponent) editors: QueryList<ChildComponent>;

ngAfterViewInit() {
let myChildComponents = this.editors.toArray();
}

NOTE: you cannot access the child components inside of ngOnInit as the child components have not become available yet. ContentChildren and QueryList are both found inside of @angular/core.

The benefit of ContentChildren over the traditional AngularJs's transclude is that the child component need not know about the parent component. This is great because a common design pattern is top down (example a tab component).

The real hidden gem here though is creating a system where you can have an abstract base class for your child components. Through doing so you can achieve a polymorphic system which lets you combine multiple like components with a base class.

Lets say for example, you have a dropdown of question types that a user can choose to answer with. You could either couple all of the editors and have them hard coded into the component that produces this part of your website, OR you could have a container ccomponent which accepts any number of different editors which are just placed in and magically work! I much prefer magic, so lets have a look at the markup that could achieve this

the contents of question-editor don't matter yet, so lets have a think of what information we would require from each of our editors (foo and bar). first we would need to be able to hide then when they are in-active, then get some sort of human friendly name and finally get the value that the form has extracted from the user. this contract could be forfilled with the following abstract class (using abstract class over interface as interfaces are compile time only, and I need something injectable!)

as this editor is a test editor, there is no complicated editor logic inside of the component, but theoretically in a real world situation there would be. What makes this editor unique to the foo editor is that it allows the user to enter an answer via an input field which we can see inside of the template.

The other thing to notice here, is that we are providing the angular DI system an implementation of the BaseEditor through use of the ExistingProvider provider (as seen inside of @Component's providers array). This provider basically tells angular, if somebody asks about BaseEditor, I'm your man! As we are defining this provide at the component level, we don't have to worry about breaking the DI every time we define a new editor either as the provide is scoped to this component and under.

the part to take note of is the @ContentChildren. As you can see, we request all children of this component which have the type of BaseEditor. Both FooEditor and BarEditor have setup their DI to point all requests for BaseEditor to themselves, so as we scan over the components, each editor is picked upa as a BaseEditor and placed inside the array for editors. The remainder of the code in the component are used to hide, display and gather input from the editors.

as you can see, we are using our list of editors to create options for our select, then displaying it inside of our component via ng-content.

In summary: @ContentChildren is an amazing new tool for every angular developers utility belt. It allows for creating top down architectures and with some DI wizardry, it also allows for polymorphic designs to be created!