ここから、幾つか思った事を、サッカー見ながらお酒飲みながら、ダラダラ書く。※ちなみに、日本vsオランダ戦見てる。今作ってるrailsアプリのjs周辺の作りを振り返ると、以下の流れで推移してきた。script導入でclassが気軽に使えて、初期化処理と共通処理の記述が明快になった。結局、画面毎に分かれたfile内で自由にjsで動き回り、非常に分かり辛い共通化されたextend元のjsがあり、これはこれで非常にスパゲッティなソースを多々生んだ。この辺りの問題は昔のblogで書いた通り。Backboneこれも劇的な変化をもたらした。Backboneでjsをmodularに書く事で、今迄書いてきたソースがどれだけ罪深かったかと思った。元のjQueryダラダラソースには戻れない。Backbone自体は、非常にsimpleで、色々と構成が悩ましく、ちゃんと仕組み策定やルール化をしないと、数々のオレオレ実装を生んだ。ステップ1と比べると遥かにマシなのだが、まだまだ多くの課題があった。この生Backboneに絶望して、他のFWに移った方の気持ちは分かります。生Backboneだけで実際の現場ソース書くのは大変で現実的でない。次のplugin入れたら大分変わった。StickIt今がコレ。この構成で落ち着いた。バック開発でrails書いてるのと同じ様な感覚で書ける。基本的な作りがMarionetteに埋め込まれているので、ソースの量とテストの量も減った。データバインディングもstickitでバッチリ機能してくれる。これで、そんなに大きな問題は無くなった。この構成での、思った事をかいていく。Marionette使うと、Viewの選択肢が一気に増えるので、どれを使うべきか考えないといけない。liタグのような親子階層があれば、MarionetteのCollectionViewとItemView使えばいい。用途がはっきりしてて、Marionetteの想定の範囲内で、ここに悩みは無い。jspみたいな物)で既にhtmlは描写している物に対して、幾つかEvent等追加したい時に、どのView使うべきか悩む事になる。appliっぽい作りだとあまり無いのだろうが、普通のアプリに適用する時は頻繁に起こる。初めは、Backbone.View使えばいいと思ってた。generator-marionetteもBackbone.View出すしね。template要らないからItemView要らないし、Marionette.Viewは単体で使うメリットが無いように思えた。Marionette.View!ところが、色々書いてみて、結局、Marionette.Viewを頻繁に使うようになった。何が良いかというと、最大の利点は、uiプロパティ。このViewで頻繁に使う要素のselectorを定数みたいなimageで登録しておけば、後で、jqueryオブジェクトとして使える仕組みで、本当にちょっとした機能なのだが。これ書くと大分スッキリする!動きも分かり易い。何か変更ある時も気軽にまとめて変える事が出来る点とても良い。書くのを忘れないように。viewちなみに、結局、compositeVIewを書く機会はあまり無かった。ItemViewで済む。追記12/22:そう思ってたんだけど、最近ようやくcompositeViewの意義が分かったhttp://lxyuma.hatenablog.com/entry/2013/12/03/230652普通のアプリの初期処理をどこに書くか問題。初期処理をどこに書くか、結構悩んだ。これもSinglePageAppliなら、初めのpage決まってるだろうし、そのままApplicationにaddInitializerすれば良い。普通のアプリと初期化処理が、普通のアプリで、色んな所から呼び出すのに、globalな初期化書くのはおかしい。この書く場所が個別の画面毎に分かれていてもやっぱり、おかしい。(Applicationの初期化じゃないからね。)それで、結局、Marionette.AppRouterから呼び出されるController内の関数毎に初期処理を分けた。複数の画面毎にやる初期処理全然違うし、もし、railsと同じ感覚なら、controllerのaction毎に処理を分けるのは自然の事だし、これで良い気がする。※ちなみに、全ての画面に共通するアプリケーション自体の本当の初期化はApplication.setInitializerに入れて良いと思う。ここで話しているのは、個別の初期処理の話。erbとtemplateどっちが良いか問題Backbone書くようになって、erb離れてtemplateに生html(+軽いlogic)を頻繁に書くようになった。初めは、railsのviewのhelperが強力なので、極力erb使って、template書かないように、と考えていた。生htmlところが、生html書くのが思った以上に、(railsのviewと比較すると)快適。何を言っているかというと、railsのviewのhelperって、メソッド名やオプションの細かい仕様が独特で、頭に入らず、いつもググってる自分がいて、これが、生htmlになると、殆どそのままガリガリ書けるので、生産性が高い。出来上がった物も、確かに、railsと比べると冗長さはあるのだが、明快で変な動きをする要素が無い。生html化していくのも悪くは無い。※完璧にrailsのviewのhelper暗記してたらそれがいいかもだが特に親子階層があって、通信&イベントが発生する所は、初めからMarionettteのCollectionとItemViewを使わないと、最終的に大変になるので、初めからバラしてしまうべき。Viewと紐づけるセレクタはView内のelに書かず、regionから持って来る。上のerbの話の続きになるが、全体の見取り図となるviewは、erbに書いておくべき。最初に書いておけば、初期処理の段階で、region書いてしまえる。region見れば、全部のViewを、見渡せるので、概要掴み易いし、作業もし易くなる。コンポーネント間の連携event生Backboneを書いてる時、どうしても連携の都合で、1Viewに複数のModelを持ってて、複雑なbindingを書いたりしてしまった。これは、罪深い事で、間違っていたと思う。非常に複雑になってしまった。いうのがオレオレ実装。1Viewは関連する1つのリソースだけ、それとbindするべき。Marionetteのイベントもthis.model/this.collectionしか書けない。この仕組みに従うと綺麗になる。イベント連携の悩みそうすると、今度は、イベント連携どうするか、悩む。この解決策は多分複数あるが、書いてて行き着いたのは、viewのイベントであればMarionetteのtriggersそれ以外は、Applicationのイベント(reqres/cmd含む)。して、以下の様なイメージで動かした。それぞれのViewはそれぞれのViewに関係する事しか行わない前提。Applicationのイベントを発火!このApplicationのイベントは、担当しているControllerのAction内でbindしている。そこから、他のViewに働きかける。すると、とにかく、Controller見れば、大体の全体の流れが掴める!うん。Controllerあれば、一々、親となるApplicationViewみたいなの作る必要もない。なんか、めっちゃスッキリした。stickit前にも書いたけど、stickitが非常に良い。これも、フォームと通信を伴うような、普通のアプリであれば、目を瞑って初めから導入してしまうべき。注意すべきは、動きが見えなくなる点。想定外の動きをする事がある。Viewの更新が、非同期でsave()してる時に邪魔になる事がよくある。※編集中の項目が元に戻ったりとかね。作り次第の話なのだが。falseばんばん設定して1wayにするようにしてる。他のinputだと、おかしな動きをする事がある。これも、stickitの方でデフォルトで準備してくれてるハズなのだが、chromeならOKだけど、FFでうまく値取ってくれてない時があったりした。これは、もう仕方ないので、getVal()内で調整コード書いた。