読者です 読者をやめる 読者になる 読者になる

lxyuma BLOG

開発関係のメモ

普通のrailsアプリにbackbone適用して思った事その2

Backbone.js javascript ruby

普通のrailsアプリにbackbone適用して思った事の続き

6)深い階層のView

BackboneのView書いてると、どうしても、親子階層が必要になってくるのは、前回の記事で書いた通り。

で、更に、書いてると、親子の子の中に更に別のViewクラスとか、親子Viewとか埋めたくなってくる。

画面次第なのだが、Viewの作りとして、あるべき構成だし、その方が正しい。のだが、

最終的に、振り返ると、どこにどのViewがあるのか、全体像が掴みにくくなる。

辿るには、親から確認していかないといけない。

うーん。

イマイチである。

こういうの、Marionetteのlayoutあると助かる。

layout/Region見れば、全体像が分かるし、layoutの中にlayout組めるのも、

こういった階層化がよくあるからなのだろう。

7)誰かと一緒に作業するには、やっぱり、template必要

初めに何度か書いた通り、当初気軽に使う予定で、

ちょっとしたUIはrender内で$('<div>')で作って貼付ければ良いや!と思ってた。

が、これ書いてると、あれもこれも追加してしまい、結論、renderが長くなり、

最終的な画面imageが分かり辛く、誰かと共同作業やりづらくなる。

templateにすると、第3者でも最終系がimageし易く、編集もし易い。

とにかく、template積極的に使うべきという話。

8)逆引きは公式pageでなくて、生ソース追跡

開発していると、Backboneの動きで分からない所、

意図通りに行かない所が出て来る。

Backboneの公式ページは簡易すぎて細かな動きがよくわからない。

Backboneのソースは1fileで1500行しかないので、

doc読むより本体のソースをgrepして確かめるのが、一番早くて正確。

9)生産性は短期的には高まらない。

元々書いていたCoffeeのclass + jQueryダラダラソースと比べて、短期的な開発スピードという意味では落ちた。

これは、構成考えないといけなかったり、幾つか要因があると思うが。

なので、例えば、ちょっとしたHP作りでちょっとしたjs程度ならBackbone使わなくて良い。使っても単にスピード落ちるだけ。

じゃあ、いつBackboneが必要なのか?というと、

  • ある程度js書かないといけなくて、
  • 今後も保守改修していかなくてはいけない時。

その条件満たしているのであれば、

module毎に分かれて整理されるので、

  • 改修し易くなり、
  • テストも書き易くなり、

改修時の工数も含めた全体を見た時に生産性上がる。

例えば、開発してても仕様変更が幾つかあったが、これも気軽に実施できた。

一度js書いてもう触れない見たくないみたいな状態にはならない。

テストもしっかり書けるので、衛生的で品質も良い状態になってくれる。

こんな感じで、条件を満たして、改修も含め全体を見たら生産性やら品質やら上がってると思う。

ただ、とにかく、初めに作ってる分には、勿論、jqueryダラダラ書くよりは時間かかるので、ご注意を。

結論

  1. 現場適用:今時のjsガリガリ書くwebサービスならBackbone付けた方が良い
  2. Marionette?:いきなり、初めからBackbone+Marionette使うべき。Backboneだけだと管理大変。
  3. View親子:Mとelを繋げる為に親子階層が必要。
  4. renderの自由さ:振り回されるので、なるべくMarionetteの標準renderをメインで使って自分で書かない事。結局そこに行き着くし、これに沿うと構成が決まる。
  5. 偽物render:を作らない事
  6. 深い階層View:marionetteのlayout/Region使え。
  7. template:なるべく使うべき。render内でごにょごにょ書かない。
  8. 逆引き:Backbone本体をgrepが早くて正確。
  9. 生産性:短期的にはダラダラjQueryより時間かかる。その後の改修時も含めて全体見ると生産性高まるが。

とにかく、marionette使うべきという話。

追記

この続きを書いた

http://lxyuma.hatenablog.com/entry/2013/11/16/232855