Saturday, March 8, 2014

ShadowRoot

I did not notice that dart:html includes some basic mechanism to register new HTML element type.
Since if we add internal variables associated to a new type of element, just a basic javascript type dom tree manipulation is not sufficient. dom to object invocation is required. this createShadowRoot mechanism looks useful feature indeed.
But ideally if Dart support nested class, I will define this MyElement (see below) as inner class of the Component class. Other approach is just to merge those features into single(MyElement) class, and this looks feasible way.
but if we want to use some of techniques using annotation for fields, we may need to define MirrorHtmlElement class as the subclass of HtmlElement, and 'component' class should inherit from it.
but there were some subtlety for the order of initialization, this approach need to be investigated further..
import 'dart:html';

void main() {
  document.register('my-element', MyElement);
  document.body.children.add(new Element.tag('my-element'));
}

class MyElement extends HtmlElement {

  MyElement.created() : super.created() {
    var shadowRoot = this.createShadowRoot();
    var button = new ButtonElement()..text = '0';
    var clickCount = 0;
    button.onClick.listen((e) {
      button.text = '${++clickCount}';
    });
    shadowRoot.children.add(button);
  }
}

The HTML is nearly empty except the necessary script imports:

<!DOCTYPE html>
<html>
  <body>
    <script type="application/dart" src="custom.dart"></script>
    <script src="packages/custom_element/custom-elements.debug.js"></script>
    <script src="packages/browser/dart.js"></script>
  </body>
</html>

Parts based Programming vs Components based Programming

Dart is designed to support components based web programming.
But the meaning of 'component' looks different for each person.
For me, component is something like coarse grained composability, not fine grained reusability.
'component' would be best represented by 'component' stereo. We can combine any amplifier, preamplifier of different companies. just connecting by wires, it works.
Another example is PC mother board. We can combine any power supply, DRAM, HDD, Compact Disk, graphics board.
On the other hand, these components themselves uses parts, e.g, condensors, transisters(but these days, the amount of such parts are decreasing..).
What polymer seems trying to achieve is to provide such reusable 'part'.
Components should have bigger self consistent functionality, and should not expose the internal.
So the approach to design 'component' based framework and 'part' based framework will be different.

Such component system works because there is a fixed API/standard any component provider must follow. In programming language, that can be defined by interface.(in Dart this was strangely dropped, but we can still use abstract class).
To connect such providers and integrate functional(functorial) body, we can use generic class.
So if we use analogy, class corresponds 'part', and generic class corresponds to 'component'.