Weitere ähnliche Inhalte
Ähnlich wie 実践Backbone.Marionette 現場の悩みと解決まで (20)
Kürzlich hochgeladen (12)
実践Backbone.Marionette 現場の悩みと解決まで
- 3. 自己紹介 : 塚野 龍馬 (@lxyuma)
● ServerSide寄りWeb Developer
○ 元々SIer出身:java/rubyで法人サービス開発してた
○ 今は、弊社でCGMを開発
○ 技術Skill
■ 言語FW:Rails + Backbone
■ storage:MySQL + MongoDB
■ 他rails周辺技術
● 趣味
○ 旅行/音楽/美味しい物食べる事
○ 去年は台湾とFrance行った(今年は国内巡ろう)
○ 2013年ハマったのは、あまちゃんと叛逆
- 6. 目次(& ダイジェスト)
● 導入編
○ Angularとの比較、BackboneでのDataBindings等
● 設計編
○ Marionetteでのコンポーネント構成等
● 実装編
○ オレオレ実装を如何に回避するか?等
● テスト編
○ javascriptのtestし辛い所と救済措置
⇒これらQA形式で書いて行く。
- 21. AngularとBackboneの大人のつきあい方
● 個人Lv : Angularは監視/学習し続けるとして
● 現場Lv : まだBackboneで良いのでは?
○ ※で、AngularはWebComponent繋がって、情報整理さ
れた頃使えばいいんじゃねーの
● 大分枯れてきてる
● 情報も豊富(無料で一通り手に入る)
⇒現実解としてBackbone!
- 36. Q:component構成は?
⇒Backbone MV* in MVC model2っぽい構成
AppRouter
Controller
生成
連携event
表示
監視
Region
View
描写
html
Model/Collection
event
event
Template
元々のBackboneの基本的なMV*構成
- 48. Backboneが用意してくれる事
● $el
○ Viewは$el内のDOM要素だけを扱う
○ globalな$使って外の要素を勝手に変えない
■ やりたければさっきの連携eventをtrigger
● Model/Collection
○ 1Viewは1Modelか1Collectionだけと紐づく
○ オレオレModel/Collection作らない
■ 連携が必要なら、同じく連携event使う
● render()
○ 画面描写はrenderで行うのであって、initialize等別の関
数で画面描写するべきでない
■ initializeに書くと画面描写とそれ以外が混合><
- 51. Q:ぱっと見でViewの動きが掴めない
⇒関数名にevent入れる規約にする
● event関数名 = on + イベント名 + 対象
○ 例)onClickSaveButton / onSyncModel
● これでevents一々見なくても流れが掴める
○ Backbone.View関数名で動作を説明する必要は無い
■ (特にMarionette入れた)Backboneはviewの関数の
行数が少なくsrc見れば動きがすぐ分かるし
○ そもそも他のevent駆動programも同じ発想
■ iOS/VB等々..
○ 勿論event関数から呼ぶ別の関数は普通に名前付け(こ
れでevent駆動の関数とそれ以外で分かれる)
- 63. BackboneでのDOM/html分離
● DOMselector書かずMarionette. View.ui使う
○ TestCodeから要素掴むのもview.ui使う
○ targetもtestも中身が絡まるのをおさえる
○ 変更時の修正の起点を作る
● test用templateを基本的に作らない
○ 変更時の修正costを下げるため
○ htmlは本物のfileだけ。
● Viewは$elの範囲内だけ扱う相対View作る
○ test用template書かずに済む
○ htmlに無いので表示検証が難しいが、逆にそれでDOM
分離(logic検証spyでも可。jQuery関数自体を検証して
も意味ない)
- 79. event駆動
● FrontEnd ≒ event駆動
○ 関数はeventに応じて実行(順番通りの部分もあるが)
○ 例
■ 開発:関数A ⇒ 関数B ⇒ 関数Cを意図
■ 実際:関数A ⇒ click ⇒ 関数C ⇒ click ⇒ 関数B
⇒意図しない関数の組み合わせがあり得る
● 独立している関数は意識しなくていいが
● 独立していない関数は注意が必要