C#er から見た Turbolinks 3
- 2. 昔は 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 はもうすぐ２年ぐらい
- 7. Turbolinks ってなんだっけ？
❖ 簡単には Github のサイトでやっているような pjax 的な動
作を簡単に実現できる仕組み。
❖ title, body を非同期に入れ替えているけど、pushState
使って URL は変える
❖ GET リクエストだけ
❖ ページ自体をキャッシュできたりと、さらに View を高速
化する仕組みも入っています。
- 8. Turbolinks 3 の発表 🎉
❖ 皆に無効化されながらも生き残った Turbolinks が
Rails5 で 3 になる事が RailsConf 2015で発表され、現在
も活発に開発が続けられています。
- 10. 目玉機能の Partial Replacement
❖ title, body だけでなく細かく制御できるようになった
❖ client, server side の両方でキーワードを指定することで、
部分的に更新する箇所、しない箇所を指定できる
❖ client side は data-turbolinks-temporary, data-turbolinks-
permanent をタグに指定をすることで切り替え
❖ server side は redirect_to, render 時に change, keep のキー
ワードを指定することで切り替え
- 16. その前に ASP.NET
❖ Ruby/Rails の方にはあまり馴染みが無いかも
❖ Windows Formを無理やりWebに持ってきたというのが
簡単な説明
❖ Web なのにステートフルという点では Java の Wicket
がちょっと近い。
❖ 今はオワコンと化して ASP.NET MVC にとって変わら
れた
- 18. そして ASP.NET Ajax
❖ Ajax の流れに完全に乗り遅れた MS が出した超兵器
（ ASP.NET MVC の爆誕前）
❖ JS を書かないっていう点では Google Web Toolkit を思い
出したり
❖ JS を書くこと無くモーダルやインクリメンタルサーチとか
を特殊なタグを書くことで実現できる💡
❖ なんかコンポーネントっぽい！
- 19. でも ASP.NET Ajax は失敗した💀
❖ 簡単な画面なら良かったんですよね。。
❖ Wicket よりもステートフルのやり方が良くなかった（状
態を全部 hidden に書き出しだと。。）
❖ Ajax の機能も特殊なタグでやり過ぎて、自動生成な
JavaScript が実行時に大量に流れた
❖ よって、複雑な画面を作ろうとすると、エラーが発生しデ
バッグも困難になった 😖
- 23. レスポンスから見る ASP.NET Ajax と Turbolinks 3 の違い
❖ ASP.NET Ajax の部分更新では、例えば POST した時のレスポンス
は、UpdatePanel で指定した部分だけのフラグメント HTML が返
される
❖ 一方で、Turbolinks 3 の場合は、リクエストしたアクションの戻り
値の HTMLがそのまま返される。
❖ 基本は pjax なので、非同期実行ができない場合でも、その画面
がレンダリングできるようにしたい
❖ つまり、本当に部分的にしか画面を更新しない場合にはほとんど
が無駄なレスポンスになる
- 24. Turbolinks 3 の有利な点
❖ Turbolinks 3 は元々が pjax 的な感じなので、当然別の
Controllerへのリクエストもできる
❖ ASP.NET は原則 POST は自身の Controllerにしかできない
❖ つまり最初のレンダリングが終われば、画面の各パーツは
POST 先の異る別々のコンポーネントとして振る舞える
❖ でも見た目いつもの Rails のコードと変わらない
❖ change, keep みたいなキーワードはあるけど
- 29. Rails らしいバランス感覚
❖ 「部分更新」と聞いてまず思うのは、 Turbolinks なんか使わずに
SPA として作って、JavaScript のフレームワーク使った方がいいよ
うに思える、がそうしなかった。
❖ 思い出すのは、Model の肥大化を防ぐのに、新たな層を入れて整理
する事もできるが、それはせず concerns を導入するだけに留めた
❖ みんながそんな複雑なアプリを作るわけじゃない
❖ 本当に複雑な事は解決できないかもしれないが、シンプルに解決で
きる事を増やしていくようなアプローチ？（個人の感想）
- 31. Turbolinks 3 を使うべきか？
❖ あなたのチームが JavaScript に十分熟知していて、メン
テナンスする時間も取れそうであり、今後もどんどん画
面が複雑化していきそうであれば、React.js のようなフ
ロントエンドのフレームワークを使うべきだと思います
- 32. Turbolinks 3 を使うべきか？
❖ 一方で、JavaScript が苦手なメンバーが多く、そこに投
資もできないのであれば、Turbolinks 3 は１つの選択肢
になりうると思います。
❖ ただし、本当に複雑でインタラクティブな画面を作りた
い時は、いずれフロントエンドのフレームワークを使う
必要があるということは考えなくてはいけないと思いま
す 😤
