Currently its really difficult for a MobileFrontend component to have several child components.
This is evident in the fact that we have many ways of doing this.
** Method 1: toHtmlString **
Certain classes have a method toHtmlString which allows us to inject the HTML of a component into a larger component
Consider a template
```
<div>
{{{icon}}}
</div>
```
We do the following:
```
var myIcon = new Icon( options );
template.render( {
icon: myIcon.toHtmlString()
} );
```
The problem with this, is all the other data inside myIcon is lost. As @krinkle points out in T149909 this is an extremely wasteful way just to get some HTML and the output is not tied to the code that created it.
** Method 2: Icons **
Identical to method 2, but we make use of a template partial:
```
<div>
{{#myIcon}}{{>anchor}}{{/myIcon}
</div>
```
```
var myIcon = new Icon( options );
template.render( {
myIcon: myIcon.options
} );
```
Exact same problems as method 1.
** method 3: View.prototype.postRender **
Any View can extend postRender to add subcomponents.
Template:
```
<div>
<icon-placeholder></icon-placeholder>
</div>
```
code:
```
postRender: function () {
var myIcon = new Icon( {} );
this.$( 'icon-placeholder' ).replaceWith( myIcon.$el );
}
This is great as it means the icon.$el is linked up to the component itself.
However, it's a little annoying as every component needs to extend the parent class and provide its own postRender
This is why we have lots of classes that extend Overlay's.
It's not great if you want to use composition rather than inheritance.
*** A new way - children **
If our view's had a concept of children, we could pass other components to them.
This avoids the CategoryOverlay extends Overlay problem as CategoryOverlay becomes an Overlay with certain children:
```
return new Overlay( {
className: 'category-overlay overlay',
heading: mw.msg( 'mobile-frontend-categories-heading' ),
headerButtonsListClassName: 'header-action',
headerButtons: headerButtons,
children: [
new CategoryWidget(
util.extend( {}, options, {
subheading: mw.msg( 'mobile-frontend-categories-subheading' )
new PromisedView(
gateway.getCategories( options.title ).then( function ( categories ) {
var subheading = categories.hidden.length || categories.visible.length ?
mw.msg( 'mobile-frontend-categories-subheading' ) :
mw.msg( 'mobile-frontend-categories-nocat' );
return new CategoryWidget(
util.extend( {}, options, {
subheading: subheading,
children: [
new TopicTitleList( {
headings: categories.visible
} ),
new TopicTitleList( {
headings: categories.hidden
} )
]
} )
);
} )
)
]
} );
```
Under the hood, this would work similar to "method 3" but automate that in such a way that no inheritance is needed to be made use of. We would need to designate an area for children to go (in my POC below I suggest a data-children attribute, and if absent, simply append to the top level DOM node)
The problem with this approach is where to put the children.
It is similar to how React does stuff but with a bit of a limitation.
For instance in React (jsx) you can do the following:
```
<div>
<ChildOne />
<div>
<AnotherChild />
<div>
{children}
</div>
</div>
</div>
However in our View's an element would only be able to have a sequence of children - not children in different places.
I think this is okay and not too much of a trade off.
A POC exists in : https://gerrit.wikimedia.org/r/468186 and I'd love us to pursue it further.