1. goog.ui.Componentのはぐれ方
アリエル・ネットワーク開発部 高村

2. 私
高村壮一（@stakamur）
HTMLとCSSをひたすら書く
↓
jQuery
↓
vimとのであい
↓
Closure Library
↓
こないだから Sencha Touch ..
開発部UIチームで働いています

3. github projects
piglovesyou / flickGal (jQuery)
piglovesyou / closure-scroller
piglovesyou / closure-thousandrows

4. yan-yan-yahuoku.com
・・・あとは、Closure Library を使って作ったウェブサービスを、最近公開しました。
ヤンヤンヤフオクといって、ヤフオクの大量の商品を、軽い動作で一覧できるのが特徴です。
このサービスを作る前に、ひとつ試したいことがありました。それが、

5. goog.ui.Component インスタンスを
徹底的にツリー化しよう
・・ということです。

6. /** @constructor */
app.ui.Component = function () {
goog.base(this);
var child = new app.ui.Another();
this.addChild(child);
};
...
ツリー構造とは、画面の各構成部分を全てui.Componentで管理させた上での、
それらの親子関係のことです。

7. app
child child
child child

8. ツリー化することは、
とくべつなアイデアではない。
むしろ、Closure LibraryにはaddChildなどのメソッドがあることから、奨励していると思う

9. http://tiny-word.appspot.com
伊藤 千光さん が書かれた、Closure 本のデモでも、
コンポーネントのツリー化を基礎に設計されています。

10. ツリー化は、基本。
（例外はやまほどあるだろう）

11. しかし、ツリー構造を作りにくいときも・・
ルールがあるところに例外はつきもの。
ルールから外れたときこそ、フレームワークの真価が問われる。
そこで、今日お話したいのは、・・・

12. 前半：なぜ、goog.ui.Componentを 後半
ツリー化すべきなのか？

13. tを 後半：goog.ui.Componentのはぐれかた
？ ツリー化する上での例外ケース３種類

14. 前半：なぜ、goog.ui.Componentを
ツリー化すべきなのか？

15. はじめに：goog.ui.Componentの簡単な説明
ui.Component は、UIモジュールです。

16. http://closure-library.googlecode.com/svn/docs/class_goog_ui_Component.html
クラス関係です。

17. http://closure-library.googlecode.com/svn/trunk/closure/goog/demos/index.html

18. インターフェース

19. var component = new app.ui.Component();
component.render();
インターフェースです。
どこかのコードで、こう書くと、componentは自分でelementを作り出し、同時にdocument.body 配下に
elementをappendします。

20. var component = new app.ui.Component();
var el = goog.dom.getElement(‘component-wrapper’);
component.decorate(el);
似た機能で、decorate があります。elementのcreateとappendのコストをはぶけ、パフォーマンスの向上が
見込めます。
しかし、アプリではelementの動的な生成が基本なので、decorateに関しては今日は触れません。

21. 実装

22. app.ui.Component.prototype.createDom = function () {
var dh = this.getDomHelper();
this.setElementInternal(dh.createDom('div', null));
};
app.ui.Component.prototype.enterDocument = function () {
goog.base(this, ‘enterDocument’);
this.getHandler().listen(this.getElement(),
‘click’, function() {(‘handle on click’);});
};
createDom では、自分が管理するelementを作り、それをメンバーにセットします。
enterDocumentは、elementが必ずあることが前提のコードを書く場所です。

23. なぜ、element生成とenterDocumentが
分かれているのか

24. コンストラクタ
↓
createDom
↓
enterDocument
↓
exitDocument
↓
dispose
elementがないと、エラーになってしまう処理を、enterDocumentに集めることで、
ui.Componentの安全で効率的なライフサイクルを提供できるからです。

25. コンストラクタ
↓
createDom
↓
• DOM Exception を防ぐ enterDocument
• enter したときだけ
↓
listener を持たせられる
（exit したら外せる） exitDocument
↓
dispose
このステップを踏むことで、ブラウザJavascriptにありがちなDOM Exception を防ぐことができます。
あとは、exitDocumentで、よけいなリスナ関数を除去することで、パフォーマンス、メモリ効率も上げられ
ます。

26. goog.ui.Componentの
簡単な説明 おわり

27. 前半：なぜ、goog.ui.Componentを
ツリー化すべきなのか？
あらためまして。

28. ３つの理由

29. 逆に、もし大量のインスタンスを
ツリーで管理しなければ、どうなる？

30. http://closure-library.googlecode.com/svn/docs/class_goog_ui_Component.html
まず、スーパークラスであるgoog.Disposable の恩恵を受けられなくなります。

31. var component = new app.ui.Component();
(‘...’);
component.dispose();
goog.Disposeは、もっともベーシックな破棄機能を提供します。

32. var component = new app.ui.Component();
(‘...’);
component.dispose(); // 内部オブジェクトの参照の破棄
// element と参照の破棄
// リスナの破棄
// 子インスタンスのdispose
disposeの実装のおかげで、インスタンスは自分に責任のがる他のオブジェクトを確実に破棄することができ
ます。
更に、ツリー構造にしておけば、子インスタンスのdisposeも走らせてくれます。

33. 理由その１：（ツリーにしないと）
関連するインスタンスのdisposeが、
大変になる。
もし

34. http://closure-library.googlecode.com/svn/docs/class_goog_ui_Component.html
次に、EventTarget の恩恵も得られなくなります。

35. var component = new goog.ui.Component();
goog.events.listen(component, 'shout', function(e) {
console.log('shut up!!!');
});
component.dispatchEvent('shout');
EventTargetは、自身をelementのようなイベントターゲットのターゲットにします。
これにより、Observer パターンを提供します。

36. 大量のインスタンスが、
お互いに通信し合う必要があったら？
では、もし大量のインスタンス同士が・・・？
大変です。

37. 参照をみつけだし、ひとつひとつ
listenするのは大変・・・
listen listen listen
まず、イベントをlistenするために参照を得なければなりません。また、インスタンスの数だけリスナが必要
になるでしょう。
シングルトンのEventTarget を利用したりもするかも知れない。
それはとてもいいことだけど、いつもそれをするとイベントが複雑になりすぎる。

38. var parent = new goog.ui.Component();
goog.events.listen(parent, 'shout', function(e) { ('shut up!') });
for (var i=0; i<10; i++) {
var child = new goog.ui.Component();
child.setParentEventTarget(parent);
}
child.dispatchEvent('shout');
それを解決するのが、EventTarget のメソッドである、setParentEventTargetです。
これにより、インスタンス同士の関係を築くことができます。

39. bubbling
parent
capture
child.dispatchEvent()
DOMと同じ。子で発生したイベントは、ルートインスタンスまで通知されます。

40. listen は１回。
イベントが勝手に飛んでくる。
listen
dispatch
dispatch dispatch
listenは１回でok。子がdispatchしたイベントは、親のもとに自動的に集められます。
子は、親に処理をデリゲートできるので、できることも増えます。

41. listen
DOMイベントと同じ。
Bubbling/Capture が利用可能
離れていても同様。DOMイベントと同じく、ルートにあたるインスタンスまでイベントは届きます。

42. 理由その２：関連するインスタンス同士の
通信が、効率的になる。

43. ３つめ

44. 毎回、レンダーツリーに
変更を加えていませんか？
３つめの、理由です。

45. http://jsperf.com/appending-to-render-tree

46. http://jsperf.com/appending-to-render-tree

47. for (var i=0; i<10; i++) {
var component = new goog.ui.Component();
component.render(); // XXX: Don’t do this!
}
もしこう書いたら、jsperfの例と同じこと。
毎回レンダーツリーにelementをappendしていってしまっています。

48. 関連するelement（DOMツリー）の
appendは、１回で。
・・・こう実装すると、確実です。

49. /** @constructor */
app.ui.Parent = function () {
goog.base(this);
for (var i=0; i<10; i++) {
this.addChild(new app.ui.Child());
}
};
(‘...’);
まず、親のコンストラクタで、子のインスタンスを生成。

50. app.ui.Parent.prototype.createDom = function () {
(‘...’);
this.forEachChild(function(child) {
child.createDom();
dh.appendChild(
this.getContentElement(),
child.getElement());
}, this);
};
次に、親のcreateDom内で、子も一緒にcreateDomし、そのあとにappend先を決定します。

51. 親コンポーネント 子コンポーネント
コンストラクタ コンストラクタ
手動
↓
createDom、
createDom
手動 親のelementにappend
↓
enterDocument enterDocument
自動
↓
exitDocument enterDocument
自動
↓
dispose dispose
自動
new と、createDom のみchildの挙動を指定をすれば、あとはgoog.ui.Componentが
親コンポーネントのライフサイクルにそって、子も同じ運命をたどります。

52. 親コンポーネント 子コ
コンストラクタ コン
↓
c
parent.render() createDom
親の
（bodyに、１度だけ
↓
appendされる）
enterDocument en
↓
exitDocument en
↓
parent.dispose()
dispose
インターフェースから見る処理の流れは、こんな感じ。
したがって、子は基本的にrenderメソッドを使わない、といえると思います。（もちろん、使うこともでき
る）

53. 理由その３：
親のcreateDom → 子のcreateDom で、
安全にDOMを組み立てられ、
効率よくappendすることができます。
その３まとめ。

54. parent.addChild(child, true); を使えばいい
（ ）
という方もいるかも知れませんが、
基本形はこの形で考えます

55. 理由その１：インスタンスのdisposeが、大変になる。
理由その２：インスタンス同士の通信が、効率的になる。
理由その３：１回のappendで済む。
DOM Exception のリスクも減らせる。
以上３点が、「なぜツリー化するのか」の理由です。

56. ツリー化するメリットが
理解いただけたかと思います

57. 前半：なぜ、goog.ui.Componentを 後半：
ツリー化すべきなのか？
十分理解していただいたところで。

58. tを 後半：goog.ui.Componentのはぐれかた
？ ツリー化する上での例外ケース３種類
後半は、この基本形からそれなければいけないケースを、３例、紹介したいと思います。

59. ツリーの基本形からはぐれる、
３つのケースを紹介します

60. goog.ui.Thousandrows を
ちょっとだけ紹介させてください
まず、１つめを紹介する前に。
僕の作った、Thousandrows について紹介させてください。

61. • 大量の行を、すぐ表示
• つなぎ目なしでスクロール（≠ページング）
• 任意の箇所にジャンプ（≠単なる無限スクロール）
大量の行を効率よく表示できる、UIコンポーネントです。

62. http://stakam.net/closure/120722/

63. Page
Row
Thousandrows
コンポーネントの親子関係を築いているので、
rowsのdisposeも効率的にでき、インスタンス間通信もしやすく、
Thousandrowsが一体となって機能することができます。

64. goog.ui.Component
↓
goog.ui.Control
↓
goog.ui.Scroller
↓
goog.ui.Thousandrows
このThousandrows を作るために、まずScrollerを作りました。継承させています。

65. Slider
Scroller
Scrollerは、こういう構造になっています。
ですが、Thousandrowsのようなものを作れるように、Sliderはchildrenに加えるわけにはいきません。

66. ケース１：関連するインスタンスを、
childに加えられないことがある

67. goog.ui.Componentの children は、
一律で contentElement_ にappendされるべき
Scroller というからには、childをcontentElement に入れていけるべきです。

68. contentElement_
Slider
Scroller

69. contentElement_
Slider
Scroller
Scrollerのchildにできない
child は、ユーザーが加えていけるようにするため、空にしておく必要がありました。

70. • childたちは、contentElement_ に並ぶようにして
おかないと、 addChildAt が動かなくなる。
（child.getElement()のsiblingに挿入してる）
• 異質のcomponentインスタンスをchildrenに
混ぜると、this.forEachChild しにくくなるので
おすすめできない。
Slider を、Scroller のchild にできない理由。

71. Scroller に関連する Slider コンポーネントを、
child にできない。
childにできないことがわかった。こんなときは、どうするか？

72. childにせず、手動で親の
ライフサイクルに追従させればOK
childにせず、手動で親のライフサイクルに追従させるという手があります。

73. 通常と同じ
/** @constructor */
goog.ui.Scroller = function () {
goog.base(this);
(‘...’);
this.slider_ = new goog.ui.Slider();
};
(‘...’);

74. 通常と同じ
goog.ui.Scroller.prototype.createDom = function () {
(‘...’);
this.slider_.createDom();
this.getElement().appendChild(this.slider_.getElement());
};

75. 通常と違う
goog.ui.Scroller.prototype.enterDocument = function () {
(‘...’);
this.slider_.enterDocument(); // 忘れずに
this.getHandler().listen(this.slider_, ‘change’, function(e) { });
//（または、this.slider_.setParentEventTarget(this) してもいいと思う）
};
child でないので、enterDocument は手動で必要になるので、忘れずに。
あとは、イベントのlistenは、slider をターゲットにして行う必要があります。
setParentEventTarget することも考えられますが、こうするとイベントがパブリックになります。

76. 通常と違う
goog.ui.Scroller.prototype.exitDocument = function () {
(‘...’);
this.slider_.exitDocument(); // なくてもいい
};

77. 通常と違う
goog.ui.Scroller.prototype.disposeInternal = function () {
if (this.slider_) {
this.slider_.dispose();
this.slider_ = null;
}
(‘...’);
};

78. ケース１まとめ：childにできない場合、
手動で状態を変えていくことで
インスタンスを管理しつづけられる。

79. ケース２：
childを、parnetの contentElement_ 以外に
appendしたいとき

80. 再び、ちょっと紹介させてください

81. タブ

82. tabs
tab tab tab
frame
タブのchild は、frameひとつです。でも・・・

83. tabs
tab tab tab
childにしたい。。
でもDOM的にとても距離がある
frame
距離がある。tab のDOMにappend することは、考えられない。

84. append先だけ、変えればOK.

85. 通常と同じ
/** @constructor */
app.ui.Tab = function () {
goog.base(this);
this.frame_ = new app.ui.Frame();
};
(‘...’);
まず、親のコンストラクタで、子のインスタンスを生成しておきます。

86. 通常と違う
app.ui.Tab.prototype.createDom = function () {
(‘...’);
this.frame_.createDom();
// 別のDOMに入れても問題ない。
dh.appendChild(
App.getInstance().getFrameWrapEl(),
this.frame_.getElement());
};
次に、親のcreateDom内で、子も一緒に

87. • childを、遠くのDOMにappendしても、特に問題ない
• parentEventTarget として機能、disposeなども
• getContentElement は、通ったらだめ。
（addChildAt も）
注意点。

88. ケース２まとめ：
DOM的関係性があまりなくても、
親子関係は築ける。

89. ケース３：ライフサイクルを
意図的にずらしたいとき

90. 先ほどの tab と frame の例は
忘れて頂いて・・・
ここ。ちょっと雑です。具体例の使いかたが雑なので注意してください。

91. タブ
もういちど出て来ました。さっきの例は忘れてください。

92. 非選択タブ。frameは、まだレンダリングしてない
タブ自身は、初期表示時にすべてレンダリングされますが、非選択のタブのフレームは、まだレンダリングし
たくない。

93. 親が選択されたときに、
子をレンダリングしたい。
（意図的にライフサイクルをずらしたい）

94. 通常と同じ
/** @constructor */
app.ui.Tab = function () {
goog.base(this);
this.frame_ = new app.ui.Frame();
};
(‘...’);
まず、親のコンストラクタで、子のインスタンスを生成しておきます。

95. 通常と違う
app.ui.Tab.prototype.createDom = function () {
(‘...’);
// frame はまだレンダリングしない。appendもされない。
};
createDom で、Tabのelement は作る。frame のelement は作らない。まだいらないから。

96. 通常と違う
app.controller.Tab.prototype.processSelected = function () {
(‘...’);
if (!this.frame_.isInDocument()) {
this.frame_.render(wrapEl);
}
};
・・・タブである自分が選択されたタイミングで、初めてframeをレンダリングします。
append先は、前述したとおり、自由な場所を指定できます。
childにしてあるので、disposeなどは、親と同じときに自動で処理されます。

97. ケース３まとめ：
必要に応じて、ライフサイクルを
ずらすことも可能。

98. • ケース１まとめ：
childにできない場合、手動で状態を変えていくことで
インスタンスを管理しつづけられる。
• ケース２まとめ：
DOM的関係性があまりなくても、親子関係は築ける。
• ケース３まとめ：
必要に応じて、ライフサイクルをずらすことも可能。

99. ツリー化のメリットと
基本のライフサイクルを理解したうえで、
柔軟にClosure Libraryからはぐれましょう！

100. おわり