改善React道

改善React道
2016/02/17 OSSユーザのための勉強会 #13
hosomichi

自己紹介
所属/肩書： JSスペシャリスト
Twitter: hosomichi(@jshosomichi)
Qiita: hosomichi(JSおくのほそ道)
最近のお仕事
・JSのテクニカルな事柄に関するよろず屋
・インターネット広告管理画面開発
・インターネット広告配信JS開発
・アプリケーション設計&開発&コードレビュー
・ツール/ライブラリ選定&導入&開発

本日のテーマ
「一年超の
React開発に於ける
私めの手法/思想と
改善の歴史を晒す」

本日のアジェンダ
1.日頃の業務開発
1-1.アプリケーションの特徴
1-2.チームの状況
2.環境構築/ライブラリについて
3.どう考えて作っているか
3-1.本日向け開発物の紹介
3-2.React周りの実装について
3-3.Flux周りの実装について

そういえば
Reactって良いの？
という方もいらっしゃると
思うので、、

「先に言っておくと『良い』と思います。
まともに動いてくれるし
パフォーマンス問題ありません。
ただReactこそ至高！とも思わないので
好きやつを使うでいいと思います！」

そのアプリケーションに求められるものが
何を重要とするのかによって
作りも影響を受けるものだと思います。
なので、まずは私めの携わっている
プロジェクトとチームについてお話することで、
イメージを共有したうえで先に進めればと思い
ます。
日頃の業務開発 > アプリケーションの特徴

『管理画面』
・一〜二ヶ月サイクルでの継続的リリース
・いわゆるCRUD的な機能を中心に提供

システム構成
HTML JS Web
Server
Web
App
Data
base
Other
App
Other
App
Other
App
・HTMLとJSは静的ファイル(サーバ生成ではない)
・画面一部品野ためにReactで作ったりはしていない
・HTMLはほぼ空で画面は1JSファイルで概ね構築
・画面とサーバーサイドは異なるリポジトリ運用
Repository A
Repository B
Web
Server
ユーザ向け配信
Ajax通信
は転送

ざっくりした特徴
・管理すべきオブジェクトの種類が多い
・１オブジェクトが持つ属性の数が多い
・オブジェクト間の関連が複雑
・ログインユーザのロールが多く、提供する機能の差異が多い

ざっくりした特徴
・管理すべきオブジェクトの種類が多い
…画面数が多い
・１オブジェクトが持つ属性の数が多い
…フォームや一覧の制御が複雑
・オブジェクト間の関連が複雑
…オブジェクト間の整合性保証とか順序管理とかが大変
・ログインユーザのロールが多く、提供する機能の差異が多い
…ロールごとの特殊処理が増えてプログラムが荒れやすい

日頃の開発では
要件が複雑化していく中、
生産性を落とさずに
継続開発できることが求められています。
そのため、メンテナンス性・拡張性を
損なわないよう綺麗な状態を保つことを
重要視しています。

初期チーム(起ち上げ期) 2人
日頃の業務開発 > チームの状況
わたくし
・基礎設計/開発
・開発ルール策定
・機能開発
・UT設計/開発
・コードレビュー
・スケジュールマネ
・インフラ調整
・システム間I/F設計
デザイナー
・要件定義
・UIイメージ/モック作成
・機能開発
やるべきことの範囲が広いが、
まだアプリもそこまで複雑ではないし、
殆どのコードに目を通している状態
なので、管理はし易い状態

七ヶ月後のチーム(拡大期) 4人
わたくし
・アーキテクチャ改善
・機能開発
・UT設計/開発
・新人育成
デザイナー
・要件定義
・機能開発
チーム長(NEW!)
・機能開発
・システム間I/F設計若手(NEW!)
・機能開発
やるべきことの範囲は狭まったが
コード量や複雑化度合いは増し、
人も増えたのでアンコントローラブル
な部分も増えました。

今年四月以降のチーム(More拡大期) 6〜8人
わたくし
・アーキテクチャ改善
・機能開発
・UT設計/開発
・新人育成
デザイナー
・要件定義
・機能開発
若手
・機能開発
更に２〜３人JOINの
予定
チーム長
・機能開発
・システム間I/F設計
コードの書き手がさらに増え、放った
らかしにしておくとカオス状態に成る
のが目に見えています。

アプリケーション複雑性が増し
人数も増えていっております。
状況に応じて、開発ポリシーの更新や
技術的なテコ入れをしないと
「アッ」という間にぐちゃぐちゃになる
ので常に改善意識が必要です。

どう考えて作っているか > 環境構築/アーキテクチャについて
ビルド
Gulp経由でｗebpackを叩いていますが、
最近はnpm scriptからwebpackを叩くように鞍替えしつつあります。
そのほうがwebpackオプションの痒いところに手がとどくためです。
いまはgulp-webserverが便利なのでGulpを撤廃はしないと思います。
watchビルドはwebpackコマンドを叩いています。
差分ビルドしてくれるのでビルド完了が速いです。
止め

環境構築/ライブラリについて
Webサーバ
gulpfile.jsはこれだけで
良いと思ってます。
gulp-webserverの機能としては
・Webサーバ
・LiveReload(JS更新時にブラウザ更新)
・プロキシ機能(Ajaxリクエストを別サーバに捌ける)
を使ってます。便利！
プロキシのURL周りに変な挙動もあるんですが。
(転送後のURL末尾に/が勝手に付く)

Browser
HTML JS Web
Server
Web
App
Web
Server
Ajax通信転送
(Gulp-WebServerのプロキシ)
このセットでボチボチ生産性あげています
コード変更
-> Webpackの
watchビルド(速い)
LiveReloadで自動ブラウザ更新

エディタ
WebStor
m
Atom
Chrome
プロダクトコードは
主にコレで書いてます。
メンバー全員使ってます。
無いと辛いです。
ライブラリを使ったりした
ちょっとしたコードスニペット
作成に使ってます。
BOMとかネイティブメソッドは
Chromeコンソール使ってます。
神補完。

ライブラリ
immutable.js
lodash
moment
constを真にconstたらしめ、脳内デー
タフローと現実を合わせるための要に
なってます。くわしくは
Qiitaにconst周りで記事書いておりま
す。
最悪無くても生きていけるんですが
車輪の再発明をしなくて良いよう
使っています。
時間処理系は
コレのおかげでだいぶコードが
シンプルになっております。

Appフレームワーク
本日のお題であるので当然ですがフレームワークはReactです。
画面遷移についてはReact-Routerを使っています。
おそらくみんなが使っている鉄板だと思います。
PC向けの画面開発はReact-Bootstrapが不足なく使いやすいです。
このUI嫌い！じゃなければおすすめです。

この勉強会の機会を頂いたので
日頃の業務開発の経験を踏まえて
アプリを作りました。
これをベースにこの先の話をしたいので、
軽く紹介しておきます。
どう考えて作っているか > 本日向け開発物の紹介

私的映画鑑賞履歴管理App
Movie Logger
ともうします
どう考えて作っているか> 本日向け開発物の紹介

MovieLoggerのモデル
1
0...1 0...3
Movie
Director Actor
1

動機
・本日の肴とするために
何かの管理画面を作りたかった
・これまでの改善ノウハウを整理して
今のベストコードをまとめたかった
・幾つかの新しい技術チャレンジをしたかった
・去年から映画にハマりだしたので
役者や監督の顔や名前を覚えたかった
・今年150本鑑賞が目標なので
今なん本なのか知りたかった

業務開発との技術的な部分の違い
・基本はほぼ同じ思想の実践
・TypeScript・Material-UIを導入
(普段はES6・Bootstrap)

機能も紹介します。
後でコードや思想を語るために
構造を事前共有したいと思います。

機能紹介(管理対象)
管理対象オブジェクトは
「映画」「監督」「俳優」の３種です
映画は監督0...1、俳優0...3の多重度で
参照を持つことが出来ます。

機能紹介(登録/編集)
タイトルを入れると
その文字列から画像検索が出来ます。
監督や俳優は予め登録した人が
オートコンプリートで設定出来ます

機能紹介(一覧)
アイテム件数を表示してます。
コレで今年何本観たか
わかります。
フィルタはプリセットで用意しまし
たが、自由度高めると
それなりに設計が要りそうです。

映画アイテムをクリックすると
紐付いてる監督・俳優が
パカーと出てきます
横のメニューで
編集ダイアログが立ち上がります

俳優さん一覧も同じノリです
名前順に並べたら
「でんでん」の存在感が半端ないです
出演作品の中で自分が観た本数や
平均レビュー点数が見れます。
パカっとやると出演作品がでます

人数、機能数共に増加していくと
皆がなるべく同じポリシー/レシピで
作れることが鍵だと思います。
ウチはReact周りでどんなポリシーを
共有しているのかを述べてまいります。
どう考えて作っているか > React周りの実装について

ウチのReactポリシー①
Prop/PropTypesはちゃんと定義する。

typescriptの
(Movie Loggerの共通コンポーネント)
React.createClassの
React.Componentの
「お外から帰ったら手を洗いなさい」的な話かと思いますが
同じ目的のpropが複数定義されてしまったりがウチではホントにありました。
isRequiredつけておけば警告挙げてくれますし、必ずやるようにしています。
Prop/PropTypesはちゃんと定義する。

ウチのReactポリシー②
Stateはしかるべき場所で集中管理。
子コンポーネントは
自分のためのStateだけを持つようにする。

Stateはしかるべき場所で集中管理
例えば右の一覧では４つの
Movieインスタンスを管理
しています。

一覧から開かれる編集画面はやはり１つの
Movieインスタンスを管理します。
※正確にはpropMovieとstateMovieの２つですが。
ココで、スタローン監督の表示部は
子コンポーネントとなっています。
右のマイナスボタンをクリックすると、
あわれスタローン監督はロッキー3から
デタッチされるというシナリオですが、
ここのコードを見てみましょう。

親側子側
・子側はStateを持たずに親のStateを貰う
・子のボタンがクリックされたら
子が持っている値を使って
親から譲り受けたコールバックを叩く。

以前、膨大・複雑かつ複数箇所で使われる
コンポーネントに対して、
コード量少なくする目的でにStateもたせたら、
改修が半端じゃなく大変な上、
どこで何やってんのかわけわかんなくなって
滅茶苦茶大変でした。。
失敗から生まれた家訓であります。
親のコードの減らし方は後述します。
今は親のコードが多少増えても
子に状態持たせることに関してはすごい慎重にします。
とは言え、親にとって不要かつ
子が必要な状態は子が持つべきでしょう。

ウチのReactポリシー③
コンポーネント共通化に固執しすぎない。

例えば、さっきの映画編集画面ですが
右のキョンキョンと三浦友和のコンポーネントは
あえて別物にしてみてます。
大きな違いは削除ボタンを
持っているかいないかだったりします。
共通化出来そうなので共通化しても良いと思います。
でも、キョンキョンのコンポーネントは候補用なので
マッチング度で色変えたいとか、三浦友和のコンポー
ネントは確定用なのでアイコン大きくしたいとか異な
る要求が降ってくる可能性が考えられます。
となると、とたんにコンポーネント内部の分岐やオプ
ションpropが増えてきます。

関数同様、共通化するという行為自体はプログラマにとって
実施すべき大切な行為だと思います。
これはJSコードも同様だと思いますが、共通化するとpropsや分
岐が増えて保守性が下がり、変更に対する柔軟性が失われてしま
う可能性があります。
共通化のメリットと同じくらいリスクを見据えて、
見た目は似ていても、本当に同じ目的に対して動作するのもの？
という疑問を投げかけるようにしています。

ウチのReactポリシー④
Reactに仕事をさせすぎない。

Reactに仕事をさせすぎない
ReactはViewに関することは一通り出来るように
機能提供されていると思います。
ソレが故に色んな仕事をさせ過ぎてViewの処理が大
変だった時期がありました。
具体的にはバリデーションと分岐処理です。
次のFlux実装の中のModelクラスについての話でお
話をします。

それなりの規模の
Reactアプリケーション開発について
語るにはReactよりFluxが本丸かと思います。
Fluxにおけるポリシーは
責務とScopeのチーム内共有を
しっかりやることを大事にしてます。
再びウチの現在のポリシーについてお話します。
どう考えて作っているか > Flux周りの実装について

ちなみにReduxとかのいわゆる
「Fluxフレームワーク」
はちゃんと使い込んだことは無いの
で
あまり詳しくないです。。
facebookのDispatcherを使ってます

まず、お馴染みのこの図ですが

うちではModelを入れています
Domain
Model

Modelの役割について

★ドメインオブジェクト１個に関するAPI提供
・コンストラクタ/ファクトリメソッドの提供
・オブジェクトデータを正しい型で保持
・セッターメソッドの提供
・バリデーションメソッドの提供
・アクション向け送信用オブジェクトの生成
Modelの役割について

・Viewのバリデーション周りの処理が煩雑で
フォームコンポーネントのコードが
荒れ気味になっていたのを解消したかった。
複数の値の有効かどうかなどを判断して
他の要素のdisable判定等するのに
shouldComponentUpdate使ったりして
面倒くさい感じになっていた。
そもそものModel導入の理由１

・映画タイトルの入力必須
・視聴済みチェックを入れていたら
・視聴年月日が0/4/6桁の
数値入力が必須
・レビューの点数選択が必須
・上記が満たされていれば
disabled=false
・左記が満たされていなければ
disabled=true
映画登録の登録ボタンが有効になる条件

モデル側の判定メソッド群
View側はシンプルになりました

・Input要素から受け取る型が文字列になるので
文字列 -> 数値の変換を誰がやるのか
はっきりさせたかった
そもそものModel導入の理由２

e.target.valueは数値ではなく数字で渡してくる。
どこからどこまで数値として扱い
どこからどこまで数字として扱うべきか・・・？
例

Modelインスタンスは正しい型で値を持つという共通認識があれば
値の変換はView側の責務となる
(業務開発のモデル側では型判定も入れたりしています)

・StoreのAPIが集合に関するものと
個に関するものが混在していたので
責務分担を綺麗にしたかった。
そもそものModel導入の理由３

そもそものModel導入の理由３
Model導入後、Storeは集合を扱うAPIのみを提供(シンプルになりました)

Modelインスタンスの
ライフサイクルについて

一覧画面について Dispatcherから受けとったペイロードから
Storeが生成してComponentに提供する。

編集画面について
一覧の各アイテムがモデルを１つ
保持しているので、、
props.movieを受け取って
state.movieに入れています

ちなみにモデルはimmutable.jsのRecordを継承していて
値を変更すると新しいインスタンスを返します。
なのでstate.movieを変更しても
props.movieが予期せず変更されることはありません。
編集画面について

フォームコンポーネントの
コンストラクタでState向けに生成
次の入力のために登録処理後に初期化
新規追加画面について

最後にウチのチームにおける
各領域のスコープ/アクセス権
について
(チーム内の決め事)

・Storeのデータが更新されるのは
Dispatcherからペイロードを受け取った時だけ
・外部向けに更新APIは提供せず、Getterだけを提供する
・自身で解決出来ない場合のみ他のストアに問い合わせのみ可能
Domain
Model

・Actionのメソッドを叩いていいのはViewだけ
・Actionは外部リソースへのアクセスを責務として
View/Store/Modelへのアクセスは行わない
Domain
Model

・Modelは他のModelにアクセスしてはいけず、
例外として、自身の属性として他のModelインスタンスと
has-a関係にある時だけアクセス可能
Domain
Model

Domain
Model
・ViewはStateとして保持しているModelのみアクセス可能
・すべての領域にアクセスよいが変更処理を実行出来るのは上記のみ

本日のコンテンツは以上でございます。
今のところはこんな内容で
うまくチーム開発は回っております。
絶対の正解は無いと思いすし、
ウチのチームのルール/ポリシーが
他のチームで機能しない部分も
多々あると思いますが
皆様のチームのお悩み解決の
参考・一助になれれば幸いで御座います。

積極採用を行っております
いっしょにJavaScriptを書きませんか？
さいごに

改善React道

Recommended

Recommended

More Related Content

Similar to 改善React道

Similar to 改善React道 (20)

改善React道