Upgrade to Pro — share decks privately, control downloads, hide ads and more …

1年半React.jsのプロジェクトに関わってみて.

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.

 1年半React.jsのプロジェクトに関わってみて.

Avatar for numanomanu

numanomanu

March 07, 2017
Tweet

More Decks by numanomanu

Other Decks in Technology

Transcript

  1. 1年半 React.js のプロジェクトに 関わってみて Tsuyoshi Numano from:Lancers 2017/03/07 【React / Digdag

    / Terraform勉強会】- 続々と新規事業を創出する、ランサーズの開発チーム -
  2. 「1年半React.jsのプロジェクトに関わってみて」と言うテーマで、導入の経緯や、その結 果をまとめました - React.js とは - ランサーズで React.js が利用されている箇所 -

    React.js 導入の経緯 - なぜ React.js (と Redux) を採用したか? - React.js を導入してどうなったか? - 現在の開発フロー全体 - 1年半 React.js のプロジェクトに関わってみて - どうやって学習するか? 今日お話しする内容
  3. 背景 2015年の7月 チャットシステムを刷新して、ユーザー体験を向上するプロジェクトが始動 - ランサーズは 2008年 12月リリース(2017年で約 9年目のプロダクト) - フレームワークは

    CakePHP - ビューファイルが、だいたいページごとに管理されている - API は導入されていない - クライアントサイドのJSがメンテしにくい状況
  4. クライアントサイド JS を改善したい - どのページで何が発火しているかわからないのでそれを追いたい - 1ページに複数のjs ファイルが呼び出されている - 1ファイルに結構な行数のコードが書かれている

    - フロントエンドに処理フローの哲学を取り入れたい - Flux などのアーキテクチャが何もない - データとビューが密結合になっている - UI をコンポーネント単位で管理したい - 同じような UI でもページ単位で管理されていたり、バラバラ - スタイルガイド的なものがない
  5. クライアントサイド JS を改善したい ユーザー体験を向上するためには... メンテナンスしにくい状態を改善したい - どのページで何が発火しているかわからないのでそれを追いたい - 1ページに複数のjs ファイルが呼び出されている

    - 1ファイルに結構な行数のコードが書かれている - フロントエンドに処理フローの哲学を取り入れたい - Flux などのアーキテクチャが何もない - データとビューが密結合になっている - UI をコンポーネント単位で管理したい - 同じような UI でもページ単位で管理されていたり、バラバラ - スタイルガイド的なものがない
  6. React.js なら望みが叶いそう - どのページで何が発火しているかわからないのでそれを追いたい - どのページでどのJSを呼ぶか、管理するクラスを作る( React.js 関係ない) - ビルドシステムを入れてファイルを分割し

    JSの管理をする(React.js 関係ない) - フロントエンドに処理フローの哲学を取り入れたい - React.js なら、Flux のフレームワークがいくつか存在 - データとビューを分離して疎結合な作りに - UI をコンポーネント単位で管理したい - React.js 自身が UI を コンポーネントごとに構築するためのライブラリ
  7. React.js を選んだ理由(2015年7月当時) - 当時はAngularJS も v1 で、 React が押してきている感じだった -

    Vue.js もそこまで盛り上がっていなかった http://www.npmtrends.com/react-vs-angular-vs-vue 2
  8. フロントに処理フローの哲学を入れたい - Flux を導入したい。 Facebook が提唱したアーキテクチャ - React.js は UI

    (view) でしかない。MVCでいう V のみ - データの動きが一方向でパターン化されているので動きが追いやすい - スタンダードに乗っかっておけば、メンテできる人が増える React.js 導入の経緯 https://github.com/facebook/flux
  9. - fluxxorや、reflux、flummox など、いろいろ選択肢はあった - Redux に決めたのは flummox の作者が、Redux の方がイケてるから そっち使ってというようなコメントを

    github に残していたり、スター数も急激 に伸びていた - 2015年7月当時、次の標準になりそうなフレームワークだった Flux のフレームワークはどれにするか? Reduxを導入 React.js 導入の経緯
  10. React.js を導入してどうなったか? 結論から言うと - Redux(Flux) が導入され、動作が追えるようになった - UIもコンポーネント単位で管理できるようになった スタンダードを採用することで、メンテできるメンバーが増えた! -

    バックエンドをAPI化することで仕事のフローが変わった - エコシステムに乗ることで、より改善に注力できるようになった 課題感については、最後にまとめます
  11. コンポーネント単位で管理できる - 以前は CakePHP の ctp ファイルにダーッと書いていた - ページ単位 →

    UI コンポーネント単位で意識せざるをえない - コンポーネントごとにファイルを分割し、組み合わせて使う
  12. コンポーネント単位で管理できる - 以前は CakePHP の ctp ファイルにダーッと書いていた - ページ単位 →

    UI コンポーネント単位で意識せざるをえない - コンポーネントごとにファイルを分割し、組み合わせて使う ステートを受け取るコンポーネント (Container Component) ステートを持たない、受け取ったデータを表示するだけのコンポーネント ( Stateless Functional Component )
  13. バックエンドをAPI化することで仕事のフローが変わった API サーバー フロントエンド バックエンド API仕様書 - 以前は CakePHPのMVC でエンジニアが一気通貫で作成

    - API仕様書を作成して、その仕様を元に、並行した開発が可能に - バックエンドが完成するまでは 仕様書からapi-mock を使ってmock サーバーを起動 このAPI仕様書の JSON返してください API仕様書どおり のJSON返します 運用方法に関してはブログにまとめました。 API仕様書をMarkDownで書き、GitHubをつかって運用する方法
  14. 開発 開発 開発 1年半の年表 2015 2016 2017 7月 プロジェクト始動 12月

    3月 7月 12月 3月 技術キャッチアップ チャットリリース ブラッシュアップ(UI、機能) プロジェクト管理リリース 新規プロジェクト始動 輪読会 本 ニュース githubリポジトリ、github issue 環境構築 プロト作成 約半年 定期的なライブラリバージョンアップ API仕様作成 開発 開発 開発
  15. プロダクトで利用している技術やコードの変化(1年半経って) - コンポーネント間の共通処理: mixin → HOC - Reduxの非同期処理: redux-thunk →

    redux-saga - Redux のロジック部分: action,reducer → middleware に集約 - ビルド関連: gulp + browserify → webpack - CSS関連: sass → CSS Modules - ステートを持たないコンポーネント: SFC - JSに型をもたせたい: FlowTypeの導入
  16. プロダクトで利用している技術やコードの変化(1年半経って) - コンポーネント間の共通処理: mixin → HOC - Reduxの非同期処理: redux-thunk →

    redux-saga - Redux のロジック部分: action,reducer → middleware に集約 - ビルド関連: gulp + browserify → webpack - CSS関連: sass → CSS Modules - ステートを持たないコンポーネント: SFC - JSに型をもたせたい: FlowTypeの導入 トレンドの変化が多くチャレンジングな環境
  17. React.js を入れたからといって、全てがうまくいくわけではない - React、 Redux の学習コストが高く、人をすぐ入れにくい - デザイナーがjsxを書くのに敷居が高く、HTML直書きより協業しにくい - Component

    の粒度が人によって違って、認識を合わせにくい - コミュニティライブラリに依存しすぎると思わぬところでハマる - データのモデリングや、ビジネスロジックの置き場に悩む - FlowType入れたけど、型を使いこなせているか不安 - gulp で管理しているプロジェクトがあり、webpackに移行できていない - トレンドを追いかけつつ、プロダクトの製作は結構忙しい React.js のプロダクトを開発、運用してみた現状の課題感
  18. React.js 採用したものの、どうやって学習する? 2015年7月時の自分のスペック - jQuery はわかる - 特にJSフレームワークを使った実務経験なし - 新卒2年目、エンジニアとしてもこれから

    - 当時は React や Redux の日本語の情報が少なかった - プロジェクトメンバーも3人で全員 React は初めて そもそも導入の時の技術選定に、自分は参加できていなかった。 (当時のリードエンジニアと現在のシニアエンジニアの方が素晴らしい方だったおかげで 今の自分があります。)
  19. まとめ React.js や Redux を導入したことによって - 処理が追えて、UIコンポーネントごとに管理できるようになった - ユーザーに価値提供するための、継続的な改善開発基盤ができた React.js

    のプロジェクトに関わってみて - 初期の導入はハードルが高い - 日々トレンドが変わったり活発なコミュニティは案外楽しい - 慣れると、以前のような開発には戻れない(戻りたくない) そもそも素人な自分にチャレンジさせてくれる会社に感謝。