普通のrailsアプリにbackbone適用して思った事その２
普通のrailsアプリにbackbone適用して思った事の続き
６）深い階層のView
BackboneのView書いてると、どうしても、親子階層が必要になってくるのは、前回の記事で書いた通り。
で、更に、書いてると、親子の子の中に更に別のViewクラスとか、親子Viewとか埋めたくなってくる。
画面次第なのだが、Viewの作りとして、あるべき構成だし、その方が正しい。のだが、
最終的に、振り返ると、どこにどのViewがあるのか、全体像が掴みにくくなる。
辿るには、親から確認していかないといけない。
うーん。
イマイチである。
こういうの、Marionetteのlayoutあると助かる。
layout/Region見れば、全体像が分かるし、layoutの中にlayout組めるのも、
こういった階層化がよくあるからなのだろう。
７）誰かと一緒に作業するには、やっぱり、template必要
初めに何度か書いた通り、当初気軽に使う予定で、
ちょっとしたUIはrender内で$('＜div＞')で作って貼付ければ良いや！と思ってた。
が、これ書いてると、あれもこれも追加してしまい、結論、renderが長くなり、
最終的な画面imageが分かり辛く、誰かと共同作業やりづらくなる。
templateにすると、第3者でも最終系がimageし易く、編集もし易い。
とにかく、template積極的に使うべきという話。
８）逆引きは公式pageでなくて、生ソース追跡
開発していると、Backboneの動きで分からない所、
意図通りに行かない所が出て来る。
Backboneの公式ページは簡易すぎて細かな動きがよくわからない。
Backboneのソースは1fileで1500行しかないので、
doc読むより本体のソースをgrepして確かめるのが、一番早くて正確。
９）生産性は短期的には高まらない。
元々書いていたCoffeeのclass + jQueryダラダラソースと比べて、短期的な開発スピードという意味では落ちた。
これは、構成考えないといけなかったり、幾つか要因があると思うが。
なので、例えば、ちょっとしたHP作りでちょっとしたjs程度ならBackbone使わなくて良い。使っても単にスピード落ちるだけ。
じゃあ、いつBackboneが必要なのか？というと、
- ある程度js書かないといけなくて、
- 今後も保守改修していかなくてはいけない時。
その条件満たしているのであれば、
module毎に分かれて整理されるので、
- 改修し易くなり、
- テストも書き易くなり、
改修時の工数も含めた全体を見た時に生産性上がる。
例えば、開発してても仕様変更が幾つかあったが、これも気軽に実施できた。
一度js書いてもう触れない見たくないみたいな状態にはならない。
テストもしっかり書けるので、衛生的で品質も良い状態になってくれる。
こんな感じで、条件を満たして、改修も含め全体を見たら生産性やら品質やら上がってると思う。
ただ、とにかく、初めに作ってる分には、勿論、jqueryダラダラ書くよりは時間かかるので、ご注意を。
結論
- 現場適用：今時のjsガリガリ書くwebサービスならBackbone付けた方が良い
- Marionette？：いきなり、初めからBackbone+Marionette使うべき。Backboneだけだと管理大変。
- View親子：Mとelを繋げる為に親子階層が必要。
- renderの自由さ：振り回されるので、なるべくMarionetteの標準renderをメインで使って自分で書かない事。結局そこに行き着くし、これに沿うと構成が決まる。
- 偽物render：を作らない事
- 深い階層View：marionetteのlayout/Region使え。
- template：なるべく使うべき。render内でごにょごにょ書かない。
- 逆引き：Backbone本体をgrepが早くて正確。
- 生産性：短期的にはダラダラjQueryより時間かかる。その後の改修時も含めて全体見ると生産性高まるが。
とにかく、marionette使うべきという話。
追記
この続きを書いた
