RailsのRailsから解放される始めの一歩

RailsのRailsから解放される始めの一歩

1. 1. RailsのRailから 解放される始めの一歩 @joe_re
2. 2. twitter: @joe_re
 github: @joe-re - 名前: じょー - freeeという会社で働いています - つい最近までクラウド会計やってました - 今はクラウド給与やってます
3. 3. 職業: gulp職人
4. 4. すみません、僕はできません
5. 5. この話のjs部分
6. 6. Sprocketsを使い続けるの つらい！
7. 7. Sprocketsがやってくれること とは • CoffeeScript、Sassのコンパイル • uglify • minify • fingerprintの付与 • 依存関係の定義(requireディレクティブの提供) • などなど
8. 8. Sprocketsを捨てたい理由 • フロントエンドのビルドツールの進化 • 基本的にgem化されていないと使えない(フロントエンドの進 化に追いつけない) • フロント側までRailsにロックインされてしまうのが気持ち悪 い • bowerが廃れた今、package.jsonに定義したnpmを直接 importして使いたい欲求がある
9. 9. Sprocketsを捨てる2つの道
10. 10. Railsのassets pipelineを一切 使わない！の道 • gulp等のビルドツールを使い、concat、 minify、uglify、fingerprint付与などの Sprocketsさんがやっている仕事を全部奪う • 成果物はPublic配下に出力する • まさしく理想の世界！
11. 11. Railsのassets pipelineを一切 使わない！の壁 • fingerprintの解決が難しい • フロント側で単純に付与しただけでは、Rails の asset_pathヘルパーが一切効かなくなる • 一気にやらないといけない作業の量やばすぎ
12. 12. フロント側の成果物をapp/assets に吐き出す！の道 • concat、uglify、minify、fingerprintなどの処 理は従来通りSprocketsにお任せ！ • まだフロントで解決できないものは、とりあ えずapp/assets配下にそのままコピーしてお けば何とかなるので、徐々に作業可能
13. 13. フロント側の成果物をapp/assets に吐き出す！の壁 • 結局Sprocketsから脱却できてない • 常にSprocketsとの良好な関係を
 意識し続けなければプロダクトが死ぬ
14. 14. 僕らはapp/assetsに成果物を 出力する道を選択した
15. 15. ゆるい方針 • xxx-railsなGemは使わない • 新しく書くコードはes2015で書けるようにし よう • npmでライブラリ管理しよう(goodbye bower)
16. 16. そこでgulpによるフロントエン ドのビルドプロセスを導入
17. 17. JavaScriptのビルド
18. 18. Sprocketsのrequire
19. 19. この順番を絶守！！！ Sprocketsのrequire
20. 20. ちくしょう、Webpackだ！！
21. 21. なんでBrowserifyじゃないの？ • 弊社のアプリケーションは複数のエントリー ポイントがある • Browserifyは開発時のwatchにおいて変更の あったファイルのインクリメンタルビルドを エントリーポイントごとに行う仕組みを構築 するのが大変
22. 22. Webpackならwatchオプショ ンにtrueを渡すだけ！！ https://webpack.github.io/docs/tutorials/getting- started/#watch-mode
23. 23. 得たもの • ライブラリはnpmで管理(これまで使っていた bower(bower-rails)とはオサラバ！) • Babelによるトランスパイル(ES2015) • CoffeeScriptのトランスパイル • ES6-modules、CommonJSによる依存解決
24. 24. さぁこれからはテストを
 書いていくぞ！
25. 25. React + Fluxの導入！
26. 26. Reduxは使わないぞ
27. 27. facebook/utilの Reduce Storeだ！
28. 28. おわり