Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Sprocketsを捨てたい

10,954 views

Published on

西日暮里.rb一周年記念 LT

Published in: Software

Sprocketsを捨てたい

  1. 1. Sprocketsを捨てたい!!
  2. 2. 自己紹介 • 名前: joe-re(じょうあー、じょー) • freeeという会社でクラウド会計作ってます。 • ぶっちゃけRubyよりJavaScriptの方が好き。
  3. 3. そもそもSprocketsってなん だっけ • Ruby製のアセットのプリプロセッサ • Rails3.1から導入 • AltJSやSassなどのcompile • concat、minify、uglify、md5フィンガープリント • 依存関係の整理がしやすくなる • develop 時にはminifyしない、など難しい設定いらずでいい感じに動 く
  4. 4. なんで捨てたいの • 最近はフロントエンドのツールが充実してる • ライブラリなど基本的にGem化されていないと使えない (導入コスト高い) • 全てを1つのファイルにConcatするので、JavaScriptの読 み込みに時間がかかる(Turbolinkうまく使えばあるいは?) • Rails5 から Rails API が本体に入る • Sprocketsに依存しないことで、Railsが死んだ時にも対応 できるようになる
  5. 5. 理想型から考える
  6. 6. 妄想 • もはや、RailsはJSON返すAPIサーバでよくね? • いいねー。フロントとサーバは完全にリポジトリ分けて、別々にCIし ようか。 • うんうん。JSONスキーマ定義して、Rails側ではそれ使ってAPIのバリ デーションして、フロント側はレスポンスモックして動かしたり、テ ストしたりするの良さそう。 • おkおk。インテグレーションテストはSelenium Web Driver使って、 マルチブラウザまで書いていく感じかな。 • :+1:
  7. 7. 現実 • jQueryのDOM操作多すぎ。心折れそう。SPAとか正直無 理な感じする。 • わかるー。そもそも複雑で人類の理解できる範囲超えて るし。コンポーネント指向っていってもなー。どこから 手をつけて良いやら…。 • ていうかそもそもフロントのテストなんて書いてないしな! インテグレーションテストなんてもちろ(rya • :cry:
  8. 8. Sprocketsと 共に生きる方法を模索する
  9. 9. とりあえずjs分割(before) • 初期状態のapplication.js # … //= require jquery //= require jquery_ujs //= require_tree . fooページにだけ必要なfooとかbarページで必要な barとかまとめられてしまう。
  10. 10. とりあえずjs分割(after) • lib.js //= require jquery //= require jquery_ujs • hoge.js //= require hoge • bar.js //= require bar
  11. 11. bowerの資産を使う • bower-rails • https://github.com/rharriso/bower-rails • これでgemになってないライブラリも使える • (とはいえbowerオワコン感がある…)
  12. 12. ビルドの成果物をSprocketsに のせる • フロントでビルドした成果物をapp/assets配下に 出力するようにする • md5フィンガープリント、minify、concat、uglify などは従来通りSprocketsさんにやってもらう • フロントに特化したビルドをしつつ、面倒な部分 はSprocketsに任せられるので扱いやすい
  13. 13. Front Engineering on Sprockets • react-rails • mithril-rails • angularjs-rails • sprockets-es6 • gulp-rails-pipeline
  14. 14. Sprocketsを捨てさる
  15. 15. 方針 • Rails は JSON を返すWebAPIにする。 • ルーティング、レンダリングなどは全てフロ ントで処理する。 • ビルドはgruntやgulpなどのフロントで使い易 いツールへ移行する。
  16. 16. フロントのビルド成果物はどこ に配置するか • 素直に Public配下が良いと思う。 • 開発中もインクリメンタルビルドで、差分だ けうまいこと Public ディレクトリに放り込ん でいく。 • 開発時にはuglifyやminifyしない。
  17. 17. proxy サーバを立てて開発を円 滑にしたい • livereload など、フロント側でやりたいことがた くさんある! • Rails 側は一度立てれば、あとは意識しなくて良く なる。(動かなければプロセス確認したり、再起動 したりする程度) • browser-sync すごく便利!
  18. 18. proxyサーバを立てた図 Rails Server localhost:3000 # endpoints GET /api/v1/friends public directory friends.js Proxy Server loalhost:8080 友達一覧が見たい! localhost:8080/friends
  19. 19. 完全に捨てるのむずい (他にいい方法あれば教えて ください。。)
  20. 20. 知見
  21. 21. 最近書いたgulp.coffee • 最近ちょうどRailsアプリケーションでgulp導 入する機会があったので紹介 • Sprockets完全廃止はできてない • ビルド結果をapp/assets配下に出力して、 Sprocketsにのせる方式
  22. 22. build tasks
  23. 23. server & watch tasks
  24. 24. 所感
  25. 25. 移行するにあたってmd5フィンガー プリントをどうにかするのは難関 • フロント側でビルドすると、そのままでは asset_pathヘルパーが効かなくなる。 • これさえどうにかできれば感はある。
  26. 26. Sprocketsの requireディレクティブうざい • browserifyと共存できないので、置き換える ときに少しずつできない。 • 少なくともファイル単位でやらないといけな い。
  27. 27. gemにassets含まれてるやつ ら、このやろう! • 単純にgem化されてるライブラリなら大抵はnpmにもあるから困ら ない。 • けど、generateでview作る系のやつはassetsが含まれてたりする。 • さすがにgulpタスクでgemファイルの中身をさらうのはなー。 • そのgem使うのをやめるのが良い。無理ならgemから抜き出してリ ポジトリにコミットするか。(バージョン管理が面倒なのでやりたく ない。。)
  28. 28. 今の気持ち
  29. 29. 少し角が取れました • そこまで完全に捨てることに拘る必要はないかも しれない(ある程度徐々に移行していくことは可能) • SprocketsはSprocketsでいいところはある(とりあ えずはそう思うことにしよう) • とはいえ新しく作るアプリケーションなら Sprocketsに頼らなくても良さそう
  30. 30. ありがとうございました

×