Webナントカ

個人開発、読んだ本、サービスの話などを書きます╭( ･ㅂ･)و ̑̑

React反省会@Wantedlyに参加してきた

勉強会

（2017/05/11追記）

  • React反省会@Wantedlyに参加したので、取り急ぎ、メモを公開します。
  • あくまで、個人のメモ書きなので、誤字脱字、認識齟齬はご了承ください。
  • 目次は敬称略ですが、ご了承ください。

React反省会@Wantedly

天野 祐介

サイボウズ株式会社 グローバル開発本部 kintone開発チームリーダー。

  • どうチームに浸透させたか
  • フロント専任はいない
  • Google Closure Tools
    • サードパーティライブラリとの相性が悪い
  • MV*ライブラリ戦争を外から眺めていた
  • 情報共有が足りなかった
  • Frontend Weekly Lunch
    • JSerInfoのazu_reさんが火曜日のお昼までにあげてくれるようにしてくれた
  • React + Redux or Flux Utils + Flow
  • 新しいパーツを作る時にReact化
  • ペアプロ
  • 新規で採用するのが一般的に
  • Fearless Changeという本を読むと良い
    Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

    Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

    • 作者: Mary Lynn Manns,Linda Rising,川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,安井力,山口鉄平,角征典
    • 出版社/メーカー: 丸善出版
    • 発売日: 2014/01/30
    • メディア: 単行本（ソフトカバー）
    • この商品を含むブログ (16件) を見る

石井 光次郎

株式会社マネーフォワード UIテクノロジー部。

  • プルリクエストを見直して、同じ議論をしている部分をまとめてみた
  • this.stateへ直接代入していいですか
    • ダメです！
    • 代入禁止
    • 再描画を伴わない変数変更がしたかった
      • 任意のインタンス変数を定義
  • React Lifecycle内でactionを発行していいか
    • ダメです！
    • 無限ループ
    • 無限ループしなければいいの？
      • それもダメだと思う
  • Reactを使うと何がいいのですか
  • ドキュメントを参考にしたけど、難しい
  • 宣言的、コンポーネントベースという概念を噛み砕けていなかった

鈴木 健太

株式会社クラウドワークス プロダクトDiv クライアントサポートG。

  • 非SPAなRailsアプリでレールに乗りつつReactを使う話 // Speaker Deck
  • 非SPAなRailsアプリにreactを入れた
  • Railsエンジニアの立場からフロントエンドの話し
  • coffeeが多い、一部でvue
  • 画面の一部をreactを導入
    • ユーザの更新に対して、画面を再描画したい部分に対して、部分的
  • sprockets => webpack
  • react_on_rails
  • react_rails
  • webpackで使うならばreact_on_railsが良さそう
  • react_on_railsでCSRFトークンを扱う
  • react_on_railsでi18n
  • react_on_railsでTurbolink
  • 反省点
    • reactのコンポーネントとRailsのViewを混ぜてしまった
      • DOMだけでなく、CSSなども二重管理になってしまった
    • RailsからReactへのデータの渡し方が甘かった
      • コンポーネントをSSRしつつAPIでも更新したい
      • SSR用とAPI用のロジックが二重管理になる
    • Viewをどちらでレンダリングするのか
  • 次にやるなら
    • 完全に分離したい
    • Railsは基本的にAPIにして、SPA的な作りにする

外村 和仁

株式会社クックパッド サービス開発部 兼 人事部。

  • BdashにおけるFlux設計 // Speaker Deck
  • @hokaccha
  • Bdash
    • SQL用のGUIツール
    • electronで開発
  • Domain Logic
    • 描画に関するｋとお以外のすべての処理
    • DBのやりとり、APIの呼び出し
    • どこにあるべきか
      • Store? Action Creator? Middleware?
      • Bdashでは、Action Creatorに入れた
    • Domain LogicをFluxから切り離した
      • StoreとDomain Logicはテストしやすくなった
      • Action Creatorはテストしづらい
  • Storeをどう分割するか
    • facebook/fluxでは、リソース毎にStoreを分割する
    • Page単位で分けてみた
    • Pageごとに独立したStoreを持つ
    • Page感で共有するデータはDomain Logic層にストアする
  • 汎用的な設計ではない
    • 今回はLocal Storageを利用したので、APIとかになるとロスが多いかも
  • 反省点
    • 他にも独自の設計・実装がいくつかある
    • コントリビューションの敷居が高くなる
    • 設計思想を共有するのが大変
  • 良かった点
    • 個人的には、きれいに設計できて満足
    • 設計を考えるのが勉強になる
      • Reduxに納得いっていなかった部分なども実は理にかなっているのが分かったり

泉 将之

ウォンテッドリー株式会社 エンジニア（インターン）

  • Performance of rendering over 10k items using React // Speaker Deck
  • Reactで多くのコンポーネントを描画する際の注意点
  • Wantedly people for PC
  • React + ReduxのSPA
  • redux-sagaからserviceを呼ぶ
  • エンジニア一人
  • 全体的にレスポンスが遅い
    • 社長からのissue
    • 2万に以上利用者がいても大丈夫なように
  • 1万に以上つながりをもっていてもちゃんと快適に検索できる
  • レンダリング回数を減らす
  • リストやアイテムの更新回数が増えがち
  • 検索時に文字入力する度にリストアイテム全県updateしていた
  • shouldComponentUpdateを適用
  • ユーザ入力のdebounce
    • lodash.debounce
    • redux-sagaでお実装可能
    • throttleだとユーザ入力を取りこぼす
  • Immutable.js周り
    • Immutalble.is()は思い
    • コレクションにis()は使うとヤバい
  • React.PureComponentを使う
  • immutableのtoJS()は重い
  • immutableのget()やhas()はO(1)ではない
    • filterとかmapするときは気をつける
  • 画面外のものは描画しない
    • react-lazyload
      • 監視するコンポーネントが多すぎる
  • react-virtualized
    • 代わりにこちらを使った
    • スクロールを監視するのはリストの親のみ
  • 巨大なリストには、react-virtualizedが有効

森脇 健人

Wantedlyのエンジニア。

  • 導入して1年経ったので、react周りの技術スタックについて反省
  • js周りの歴史
    • jquery-ujs
    • backbone
    • angular 1
    • react
  • angularは一気に全体に導入された
    • 詳しい人ひとりだけ
  • React導入時に注意したこと
    • 各人を増やすことに尽力した
    • トイレとかでReactいいよとつぶやく
    • 一部から導入した
    • デザイナーに認めてもらう
  • 結果、各人が増えた
  • 10機能、component数300ぐらい
  • webpack
    • 独立した機能から使いだして、独立したアプリケーションがっぱいできた
    • 全体に導入する際に困っている
    • 各機能が独立しているので、一気に読み込めない
    • それぞれがstoreを作って、routingしている
    • アプリケーションは一つで、lazy loadで必要なものを読み込む
    • webpackのdynamic importでできる
  • ESLint
    • もともと使っていなかった
    • すごいペースでコードが汚くなっていく
    • 途中から導入した
    • 反省点: 初めから入れて、徹底する
  • Immutable.js
    • Immutable便利
    • どこはImmutableで、どこはPlainなのかが分からなくなってくる
    • propTypesも適当になってきた
      • anyがいっぱい
    • TSを導入？
  • Containeer
    • 状態管理を行うcomponent
    • どこからContainerで、どこからcomponent
    • porpsの受け渡しが多すぎるひどいコードが増えた
    • もっと細かくContainerを分けるべきだった
  • ES2015
    • stage-3まで使える
    • それ以下は要相談
    • 型は必要だった？
    • 最近はgo-lang書く人増えてきた
    • TSのIntelisenseがいい
    • TSにしても良かった
    • 途中で入れるのは骨が折れる
    • Flowでも可
  • テスト
    • jsの単体テストはない、Railsを含めたE2E
    • テストはかけた方がいい
    • 全部E2Eで書くのは大変
  • ディレクトリ構成
    • stateとUIを分けるべき
    • componentsとcontainerはディレクトリで分けなくても良さそう
    • components/とstate/fooapp/actions, …
  • CSS
    • 普通にcss modules使えば良かった

以下、飛び込みLT

ReactでCMSを作ったときにハマったこと

  • 管理画面(CMS)の実装
  • undoやredoを実装
  • Object.assignのshallow copy
  • immutable.jsの導入
  • しがないラジオ

React + Redux 未経験者への導入

トップへ戻る