部分更新における Turbolinks 3 のマシさ

C#er から見た Turbolinks 3

@dany1468

昔は C#er だった❖ 2 年前まで 5 年ぐらいずっと C#/ASP.NET。その前は Java/Struts/

Seasar2で 2 年ぐらい。

❖ C# は 2 ぐらいから始めて、4.5 ぐらいまで触った感じ。6 とか分からん。

❖ ASP.NET は ASP.NET Ajax を経由して ASP.NET MVC は 3 ぐらいまで。

❖ C# は好きだけど、テスト書きにくいのがむむむ。

❖ Ruby はもうすぐ２年ぐらい

Turbolinks 3

その前に・・

Turbolinks の一般的なイメージ

こんな感じですよね 😅

Turbolinks ってなんだっけ？❖ 簡単には Github のサイトでやっているような pjax 的な動作を簡単に実現できる仕組み。

❖ title, body を非同期に入れ替えているけど、pushState

使って URL は変える

❖ GET リクエストだけ

❖ ページ自体をキャッシュできたりと、さらに View を高速化する仕組みも入っています。

Turbolinks 3 の発表 🎉

❖ 皆に無効化されながらも生き残った Turbolinks が

Rails5 で 3 になる事が RailsConf 2015で発表され、現在も活発に開発が続けられています。

🚀目玉機能 の Partial Replacement

目玉機能の Partial Replacement

❖ title, body だけでなく細かく制御できるようになった

❖ client, server side の両方でキーワードを指定することで、部分的に更新する箇所、しない箇所を指定できる

❖ client side は data-turbolinks-temporary, data-turbolinks-

permanent をタグに指定をすることで切り替え

❖ server side は redirect_to, render 時に change, keep のキーワードを指定することで切り替え

部分更新ができればもっと高速に画面の切り替えができる❓

ちょっと待て・・ 部分更新と言えば・・😧

ASP.NET Ajax❖ 皆さんはこの単語をご存知でしょうか？

その前に ASP.NET❖ Ruby/Rails の方にはあまり馴染みが無いかも

❖ Windows Formを無理やりWebに持ってきたというのが簡単な説明

❖ Web なのにステートフルという点では Java の Wicket がちょっと近い。

❖ 今はオワコンと化して ASP.NET MVC にとって変わられた

いや、言うほど悪くないですよ 😅

そして ASP.NET Ajax❖ Ajax の流れに完全に乗り遅れた MS が出した超兵器（ ASP.NET MVC の爆誕前）

❖ JS を書かないっていう点では Google Web Toolkit を思い出したり

❖ JS を書くこと無くモーダルやインクリメンタルサーチとかを特殊なタグを書くことで実現できる💡

❖ なんかコンポーネントっぽい！

でも ASP.NET Ajax は失敗した💀❖ 簡単な画面なら良かったんですよね。。

❖ Wicket よりもステートフルのやり方が良くなかった（状態を全部 hidden に書き出しだと。。）

❖ Ajax の機能も特殊なタグでやり過ぎて、自動生成な

JavaScript が実行時に大量に流れた

❖ よって、複雑な画面を作ろうとすると、エラーが発生しデバッグも困難になった 😖

特に辛かった部分更新❖ 一番便利でかつ、一番悩ましかったのが部分更新

❖ <asp:UpdatePanel> という魔法のタグ１つで、そこが部分更新の対象となる😳

❖ よくなかったのは部分更新によって異る機能を持つコンポーネントが画面にあるような作りなのに、全て一つの Controller で捌く必要があったこと

❖ MVP パターン使って Presenter を作るなどしてマシにはできたが、基本はどんどんコードが肥大化 😩

UpdatePanel

それもあって最初の感想

❖ 「DHH さん、やっちまったな。。😷」

❖ と Turbolinks の引き続きの無効化を誓ったのでした

レスポンスから見る ASP.NET Ajax と Turbolinks 3 の違い

❖ ASP.NET Ajax の部分更新では、例えば POST した時のレスポンスは、UpdatePanel で指定した部分だけのフラグメント HTML が返される

❖ 一方で、Turbolinks 3 の場合は、リクエストしたアクションの戻り値の HTMLがそのまま返される。

❖ 基本は pjax なので、非同期実行ができない場合でも、その画面がレンダリングできるようにしたい

❖ つまり、本当に部分的にしか画面を更新しない場合にはほとんどが無駄なレスポンスになる

Turbolinks 3 の有利な点❖ Turbolinks 3 は元々が pjax 的な感じなので、当然別の

Controllerへのリクエストもできる

❖ ASP.NET は原則 POST は自身の Controllerにしかできない

❖ つまり最初のレンダリングが終われば、画面の各パーツは

POST 先の異る別々のコンポーネントとして振る舞える

❖ でも見た目いつもの Rails のコードと変わらない

❖ change, keep みたいなキーワードはあるけど

ふむ、それなら使いどころあるかも 💡

DEMO https://github.com/dany1468/turbolinks3-playground

demo ブランチ

コンポーネント指向に画面を作る❖ 最近ではクライアントサイド、特に React.js 等のフレームワークがコンポーネントに UIとロジックを閉じ込めて画面を作るように設計されていたりします。

Turbolinks とコンポーネント

❖ Turbolinks では UI と Logic は相変わらず Controller と

View で離れています。

❖ しかし Partial Replacement によって、それらの組み合わせが１つの画面内で独立して振る舞う事を可能にしています。

Rails らしいバランス感覚❖ 「部分更新」と聞いてまず思うのは、 Turbolinks なんか使わずに

SPA として作って、JavaScript のフレームワーク使った方がいいように思える、がそうしなかった。

❖ 思い出すのは、Model の肥大化を防ぐのに、新たな層を入れて整理する事もできるが、それはせず concerns を導入するだけに留めた

❖ みんながそんな複雑なアプリを作るわけじゃない

❖ 本当に複雑な事は解決できないかもしれないが、シンプルに解決できる事を増やしていくようなアプローチ？（個人の感想）

Rails の進む道❖ RailsConf の DHH のキーノートでとてもらしい発言がありました

❖ http://tech.misoca.jp/entry/2015/05/08/170112

Turbolinks 3 を使うべきか？

❖ あなたのチームが JavaScript に十分熟知していて、メンテナンスする時間も取れそうであり、今後もどんどん画面が複雑化していきそうであれば、React.js のようなフロントエンドのフレームワークを使うべきだと思います

Turbolinks 3 を使うべきか？

❖ 一方で、JavaScript が苦手なメンバーが多く、そこに投資もできないのであれば、Turbolinks 3 は１つの選択肢になりうると思います。

❖ ただし、本当に複雑でインタラクティブな画面を作りたい時は、いずれフロントエンドのフレームワークを使う必要があるということは考えなくてはいけないと思います 😤

メンテ不能な JavaScript コードを生み出すぐらいなら Turbolinks 3 を検討してはいかがでしょう

か？