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.
改善React道
2016/02/17 OSSユーザのための勉強会 #13
hosomichi
自己紹介
と申します
自己紹介
所属/肩書: JSスペシャリスト
Twitter: hosomichi(@jshosomichi)
Qiita: hosomichi(JSおくのほそ道)
最近のお仕事
・JSのテクニカルな事柄に関するよろず屋
・インターネット広告管理...
本日のテーマ
「一年超の
React開発に於ける
私めの手法/思想と
改善の歴史を晒す」
本日のアジェンダ
1.日頃の業務開発
1-1.アプリケーションの特徴
1-2.チームの状況
2.環境構築/ライブラリについて
3.どう考えて作っているか
3-1.本日向け開発物の紹介
3-2.React周りの実装について
3-3.Flux周りの...
そういえば
Reactって良いの?
という方もいらっしゃると
思うので、、
「先に言っておくと『良い』と思います。
まともに動いてくれるし
パフォーマンス問題ありません。
ただReactこそ至高!とも思わないので
好きやつを使うでいいと思います!」
本日のアジェンダ
1.日頃の業務開発
1-1.アプリケーションの特徴
1-2.チームの状況
2.環境構築/ライブラリについて
3.どう考えて作っているか
3-1.本日向け開発物の紹介
3-2.React周りの実装について
3-3.Flux周りの...
そのアプリケーションに求められるものが
何を重要とするのかによって
作りも影響を受けるものだと思います。
なので、まずは私めの携わっている
プロジェクトとチームについてお話することで、
イメージを共有したうえで先に進めればと思い
ます。
日頃の...
日頃の業務開発 > アプリケーションの特徴
『管理画面』
・一〜二ヶ月サイクルでの継続的リリース
・いわゆるCRUD的な機能を中心に提供
システム構成
HTML JS Web
Server
Web
App
Data
base
Other
App
Other
App
Other
App
・HTMLとJSは静的ファイル(サーバ生成ではない)
・画面一部品野ためにReactで作ったりは...
ざっくりした特徴
・管理すべきオブジェクトの種類が多い
・1オブジェクトが持つ属性の数が多い
・オブジェクト間の関連が複雑
・ログインユーザのロールが多く、提供する機能の差異が多い
日頃の業務開発 > アプリケーションの特徴
日頃の業務開発 > アプリケーションの特徴
ざっくりした特徴
・管理すべきオブジェクトの種類が多い
…画面数が多い
・1オブジェクトが持つ属性の数が多い
…フォームや一覧の制御が複雑
・オブジェクト間の関連が複雑
…オブジェクト間の整合性保証と...
日頃の開発では
要件が複雑化していく中、
生産性を落とさずに
継続開発できることが求められています。
そのため、メンテナンス性・拡張性を
損なわないよう綺麗な状態を保つことを
重要視しています。
日頃の業務開発 > アプリケーションの特徴
本日のアジェンダ
1.日頃の業務開発
1-1.アプリケーションの特徴
1-2.チームの状況
2.環境構築/ライブラリについて
3.どう考えて作っているか
3-1.本日向け開発物の紹介
3-2.React周りの実装について
3-3.Flux周りの...
初期チーム(起ち上げ期) 2人
日頃の業務開発 > チームの状況
わたくし
・基礎設計/開発
・開発ルール策定
・機能開発
・UT設計/開発
・コードレビュー
・スケジュールマネ
・インフラ調整
・システム間I/F設計
デザイナー
・要件定義
...
七ヶ月後のチーム(拡大期) 4人
日頃の業務開発 > チームの状況
わたくし
・アーキテクチャ改善
・機能開発
・UT設計/開発
・コードレビュー
・新人育成
デザイナー
・要件定義
・UIイメージ/モック作成
・機能開発
チーム長(NEW!)...
今年四月以降のチーム(More拡大期) 6〜8人
日頃の業務開発 > チームの状況
わたくし
・アーキテクチャ改善
・機能開発
・UT設計/開発
・コードレビュー
・新人育成
デザイナー
・要件定義
・UIイメージ/モック作成
・機能開発
若手...
アプリケーション複雑性が増し
人数も増えていっております。
状況に応じて、開発ポリシーの更新や
技術的なテコ入れをしないと
「アッ」という間にぐちゃぐちゃになる
ので常に改善意識が必要です。
日頃の業務開発 > チームの状況
本日のアジェンダ
1.日頃の業務開発
1-1.アプリケーションの特徴
1-2.チームの状況
2.環境構築/ライブラリについて
3.どう考えて作っているか
3-1.本日向け開発物の紹介
3-2.React周りの実装について
3-3.Flux周りの...
どう考えて作っているか > 環境構築/アーキテクチャについて
ビルド
Gulp経由でwebpackを叩いていますが、
最近はnpm scriptからwebpackを叩くように鞍替えしつつあります。
そのほうがwebpackオプションの痒いところ...
環境構築/ライブラリについて
Webサーバ
gulpfile.jsはこれだけで
良いと思ってます。
gulp-webserverの機能としては
・Webサーバ
・LiveReload(JS更新時にブラウザ更新)
・プロキシ機能(Ajaxリクエス...
Browser
HTML JS Web
Server
Web
App
Web
Server
Ajax通信転送
(Gulp-WebServerのプロキシ)
このセットでボチボチ生産性あげています
環境構築/ライブラリについて
コード変更
-> W...
環境構築/ライブラリについて
エディタ
WebStor
m
Atom
Chrome
プロダクトコードは
主にコレで書いてます。
メンバー全員使ってます。
無いと辛いです。
ライブラリを使ったりした
ちょっとしたコードスニペット
作成に使ってます...
環境構築/ライブラリについて
ライブラリ
immutable.js
lodash
moment
constを真にconstたらしめ、脳内デー
タフローと現実を合わせるための要に
なってます。くわしくは
Qiitaにconst周りで記事書いており...
Appフレームワーク
本日のお題であるので当然ですがフレームワークはReactです。
画面遷移についてはReact-Routerを使っています。
おそらくみんなが使っている鉄板だと思います。
PC向けの画面開発はReact-Bootstrapが...
本日のアジェンダ
1.日頃の業務開発
1-1.アプリケーションの特徴
1-2.チームの状況
2.環境構築/ライブラリについて
3.どう考えて作っているか
3-1.本日向け開発物の紹介
3-2.React周りの実装について
3-3.Flux周りの...
この勉強会の機会を頂いたので
日頃の業務開発の経験を踏まえて
アプリを作りました。
これをベースにこの先の話をしたいので、
軽く紹介しておきます。
どう考えて作っているか > 本日向け開発物の紹介
私的映画鑑賞履歴管理App
Movie Logger
ともうします
どう考えて作っているか> 本日向け開発物の紹介
MovieLoggerのモデル
どう考えて作っているか> 本日向け開発物の紹介
1
0...1 0...3
Movie
Director Actor
1
動機
どう考えて作っているか> 本日向け開発物の紹介
・本日の肴とするために
何かの管理画面を作りたかった
・これまでの改善ノウハウを整理して
今のベストコードをまとめたかった
・幾つかの新しい技術チャレンジをしたかった
・去年から映画にハマり...
業務開発との技術的な部分の違い
どう考えて作っているか> 本日向け開発物の紹介
・基本はほぼ同じ思想の実践
・TypeScript・Material-UIを導入
(普段はES6・Bootstrap)
機能も紹介します。
後でコードや思想を語るために
構造を事前共有したいと思います。
どう考えて作っているか> 本日向け開発物の紹介
機能紹介(管理対象)
どう考えて作っているか> 本日向け開発物の紹介
管理対象オブジェクトは
「映画」「監督」「俳優」の3種です
映画は監督0...1、俳優0...3の多重度で
参照を持つことが出来ます。
機能紹介(登録/編集)
どう考えて作っているか> 本日向け開発物の紹介
タイトルを入れると
その文字列から画像検索が出来ます。
監督や俳優は予め登録した人が
オートコンプリートで設定出来ます
機能紹介(一覧)
どう考えて作っているか> 本日向け開発物の紹介
アイテム件数を表示してます。
コレで今年何本観たか
わかります。
フィルタはプリセットで用意しまし
たが、自由度高めると
それなりに設計が要りそうです。
機能紹介(一覧)
どう考えて作っているか> 本日向け開発物の紹介
映画アイテムをクリックすると
紐付いてる監督・俳優が
パカーと出てきます
横のメニューで
編集ダイアログが立ち上がります
機能紹介(一覧)
どう考えて作っているか> 本日向け開発物の紹介
俳優さん一覧も同じノリです
名前順に並べたら
「でんでん」の存在感が半端ないです
出演作品の中で自分が観た本数や
平均レビュー点数が見れます。
パカっとやると出演作品がでます
本日のアジェンダ
1.日頃の業務開発
1-1.アプリケーションの特徴
1-2.チームの状況
2.環境構築/ライブラリについて
3.どう考えて作っているか
3-1.本日向け開発物の紹介
3-2.React周りの実装について
3-3.Flux周りの...
人数、機能数共に増加していくと
皆がなるべく同じポリシー/レシピで
作れることが鍵だと思います。
ウチはReact周りでどんなポリシーを
共有しているのかを述べてまいります。
どう考えて作っているか > React周りの実装について
ウチのReactポリシー①
Prop/PropTypesはちゃんと定義する。
どう考えて作っているか > React周りの実装について
typescriptの
(Movie Loggerの共通コンポーネント)
どう考えて作っているか > React周りの実装について
React.createClassの
React.Componentの
「お外から帰ったら手を洗いなさい」的な話...
ウチのReactポリシー②
Stateはしかるべき場所で集中管理。
子コンポーネントは
自分のためのStateだけを持つようにする。
どう考えて作っているか > React周りの実装について
Stateはしかるべき場所で集中管理
どう考えて作っているか > React周りの実装について
例えば右の一覧では4つの
Movieインスタンスを管理
しています。
Stateはしかるべき場所で集中管理
どう考えて作っているか > React周りの実装について
一覧から開かれる編集画面はやはり1つの
Movieインスタンスを管理します。
※正確にはpropMovieとstateMovieの2つですが。
ココ...
Stateはしかるべき場所で集中管理
どう考えて作っているか > React周りの実装について
親側 子側
・子側はStateを持たずに親のStateを貰う
・子のボタンがクリックされたら
子が持っている値を使って
親から譲り受けたコールバック...
Stateはしかるべき場所で集中管理
どう考えて作っているか > React周りの実装について
以前、膨大・複雑かつ複数箇所で使われる
コンポーネントに対して、
コード量少なくする目的でにStateもたせたら、
改修が半端じゃなく大変な上、
ど...
ウチのReactポリシー③
コンポーネント共通化に固執しすぎない。
どう考えて作っているか > React周りの実装について
どう考えて作っているか > React周りの実装について
コンポーネント共通化に固執しすぎない。
例えば、さっきの映画編集画面ですが
右のキョンキョンと三浦友和のコンポーネントは
あえて別物にしてみてます。
大きな違いは削除ボタンを
持っている...
どう考えて作っているか > React周りの実装について
コンポーネント共通化に固執しすぎない。
関数同様、共通化するという行為自体はプログラマにとって
実施すべき大切な行為だと思います。
これはJSコードも同様だと思いますが、共通化するとpr...
ウチのReactポリシー④
Reactに仕事をさせすぎない。
どう考えて作っているか > React周りの実装について
どう考えて作っているか > React周りの実装について
Reactに仕事をさせすぎない
ReactはViewに関することは一通り出来るように
機能提供されていると思います。
ソレが故に色んな仕事をさせ過ぎてViewの処理が大
変だった時期があ...
本日のアジェンダ
1.日頃の業務開発
1-1.アプリケーションの特徴
1-2.チームの状況
2.環境構築/ライブラリについて
3.どう考えて作っているか
3-1.本日向け開発物の紹介
3-2.React周りの実装について
3-3.Flux周りの...
それなりの規模の
Reactアプリケーション開発について
語るにはReactよりFluxが本丸かと思います。
Fluxにおけるポリシーは
責務とScopeのチーム内共有を
しっかりやることを大事にしてます。
再びウチの現在のポリシーについてお話...
ちなみにReduxとかのいわゆる
「Fluxフレームワーク」
はちゃんと使い込んだことは無いの
で
あまり詳しくないです。。
facebookのDispatcherを使ってます
どう考えて作っているか > Flux周りの実装について
どう考えて作っているか > Flux周りの実装について
まず、お馴染みのこの図ですが
どう考えて作っているか > Flux周りの実装について
うちではModelを入れています
Domain
Model
Modelの役割について
どう考えて作っているか > Flux周りの実装について
どう考えて作っているか > Flux周りの実装について
★ドメインオブジェクト1個に関するAPI提供
・コンストラクタ/ファクトリメソッドの提供
・オブジェクトデータを正しい型で保持
・セッターメソッドの提供
・バリデーションメソッドの提供
・...
どう考えて作っているか > Flux周りの実装について
・Viewのバリデーション周りの処理が煩雑で
フォームコンポーネントのコードが
荒れ気味になっていたのを解消したかった。
複数の値の有効かどうかなどを判断して
他の要素のdisable判定...
どう考えて作っているか > Flux周りの実装について
そもそものModel導入の理由1
・映画タイトルの入力必須
・視聴済みチェックを入れていたら
・視聴年月日が0/4/6桁の
数値入力が必須
・レビューの点数選択が必須
・上記が満たされてい...
どう考えて作っているか > Flux周りの実装について
そもそものModel導入の理由1
モデル側の判定メソッド群
View側はシンプルになりました
どう考えて作っているか > Flux周りの実装について
・Input要素から受け取る型が文字列になるので
文字列 -> 数値の変換を誰がやるのか
はっきりさせたかった
そもそものModel導入の理由2
どう考えて作っているか > Flux周りの実装について
そもそものModel導入の理由2
e.target.valueは数値ではなく数字で渡してくる。
どこからどこまで数値として扱い
どこからどこまで数字として扱うべきか・・・?
例
どう考えて作っているか > Flux周りの実装について
そもそものModel導入の理由2
Modelインスタンスは正しい型で値を持つという共通認識があれば
値の変換はView側の責務となる
(業務開発のモデル側では型判定も入れたりしています)
どう考えて作っているか > Flux周りの実装について
・StoreのAPIが集合に関するものと
個に関するものが混在していたので
責務分担を綺麗にしたかった。
そもそものModel導入の理由3
どう考えて作っているか > Flux周りの実装について
そもそものModel導入の理由3
Model導入後、Storeは集合を扱うAPIのみを提供(シンプルになりました)
Modelインスタンスの
ライフサイクルについて
どう考えて作っているか > Flux周りの実装について
どう考えて作っているか > Flux周りの実装について
一覧画面について Dispatcherから受けとったペイロードから
Storeが生成してComponentに提供する。
どう考えて作っているか > Flux周りの実装について
編集画面について
一覧の各アイテムがモデルを1つ
保持しているので、、
props.movieを受け取って
state.movieに入れています
どう考えて作っているか > Flux周りの実装について
ちなみにモデルはimmutable.jsのRecordを継承していて
値を変更すると新しいインスタンスを返します。
なのでstate.movieを変更しても
props.movieが予期せ...
どう考えて作っているか > Flux周りの実装について
フォームコンポーネントの
コンストラクタでState向けに生成
次の入力のために登録処理後に初期化
新規追加画面について
最後にウチのチームにおける
各領域のスコープ/アクセス権
について
(チーム内の決め事)
どう考えて作っているか > Flux周りの実装について
・Storeのデータが更新されるのは
Dispatcherからペイロードを受け取った時だけ
・外部向けに更新APIは提供せず、Getterだけを提供する
・自身で解決出来ない場合のみ他のストアに問い合わせのみ可能
どう考えて作っているか > F...
・Actionのメソッドを叩いていいのはViewだけ
・Actionは外部リソースへのアクセスを責務として
View/Store/Modelへのアクセスは行わない
どう考えて作っているか > Flux周りの実装について
Domain
Model
・Modelは他のModelにアクセスしてはいけず、
例外として、自身の属性として他のModelインスタンスと
has-a関係にある時だけアクセス可能
どう考えて作っているか > Flux周りの実装について
Domain
Model
どう考えて作っているか > Flux周りの実装について
Domain
Model
・ViewはStateとして保持しているModelのみアクセス可能
・すべての領域にアクセスよいが変更処理を実行出来るのは上記のみ
本日のコンテンツは以上でございます。
今のところはこんな内容で
うまくチーム開発は回っております。
絶対の正解は無いと思いすし、
ウチのチームのルール/ポリシーが
他のチームで機能しない部分も
多々あると思いますが
皆様のチームのお悩み解決の
...
積極採用を行っております
いっしょにJavaScriptを書きませんか?
さいごに
改善React道
改善React道
改善React道
Upcoming SlideShare
Loading in …5
×

改善React道

728 views

Published on

1年積み上げてきたReactアプリケーション開発の改善ノウハウ

Published in: Software
  • Be the first to comment

改善React道

  1. 1. 改善React道 2016/02/17 OSSユーザのための勉強会 #13 hosomichi
  2. 2. 自己紹介 と申します
  3. 3. 自己紹介 所属/肩書: JSスペシャリスト Twitter: hosomichi(@jshosomichi) Qiita: hosomichi(JSおくのほそ道) 最近のお仕事 ・JSのテクニカルな事柄に関するよろず屋 ・インターネット広告管理画面開発 ・インターネット広告配信JS開発 ・アプリケーション設計&開発&コードレビュー ・ツール/ライブラリ選定&導入&開発
  4. 4. 本日のテーマ 「一年超の React開発に於ける 私めの手法/思想と 改善の歴史を晒す」
  5. 5. 本日のアジェンダ 1.日頃の業務開発 1-1.アプリケーションの特徴 1-2.チームの状況 2.環境構築/ライブラリについて 3.どう考えて作っているか 3-1.本日向け開発物の紹介 3-2.React周りの実装について 3-3.Flux周りの実装について
  6. 6. そういえば Reactって良いの? という方もいらっしゃると 思うので、、
  7. 7. 「先に言っておくと『良い』と思います。 まともに動いてくれるし パフォーマンス問題ありません。 ただReactこそ至高!とも思わないので 好きやつを使うでいいと思います!」
  8. 8. 本日のアジェンダ 1.日頃の業務開発 1-1.アプリケーションの特徴 1-2.チームの状況 2.環境構築/ライブラリについて 3.どう考えて作っているか 3-1.本日向け開発物の紹介 3-2.React周りの実装について 3-3.Flux周りの実装について
  9. 9. そのアプリケーションに求められるものが 何を重要とするのかによって 作りも影響を受けるものだと思います。 なので、まずは私めの携わっている プロジェクトとチームについてお話することで、 イメージを共有したうえで先に進めればと思い ます。 日頃の業務開発 > アプリケーションの特徴
  10. 10. 日頃の業務開発 > アプリケーションの特徴 『管理画面』 ・一〜二ヶ月サイクルでの継続的リリース ・いわゆるCRUD的な機能を中心に提供
  11. 11. システム構成 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通信 は転送 日頃の業務開発 > アプリケーションの特徴
  12. 12. ざっくりした特徴 ・管理すべきオブジェクトの種類が多い ・1オブジェクトが持つ属性の数が多い ・オブジェクト間の関連が複雑 ・ログインユーザのロールが多く、提供する機能の差異が多い 日頃の業務開発 > アプリケーションの特徴
  13. 13. 日頃の業務開発 > アプリケーションの特徴 ざっくりした特徴 ・管理すべきオブジェクトの種類が多い …画面数が多い ・1オブジェクトが持つ属性の数が多い …フォームや一覧の制御が複雑 ・オブジェクト間の関連が複雑 …オブジェクト間の整合性保証とか順序管理とかが大変 ・ログインユーザのロールが多く、提供する機能の差異が多い …ロールごとの特殊処理が増えてプログラムが荒れやすい
  14. 14. 日頃の開発では 要件が複雑化していく中、 生産性を落とさずに 継続開発できることが求められています。 そのため、メンテナンス性・拡張性を 損なわないよう綺麗な状態を保つことを 重要視しています。 日頃の業務開発 > アプリケーションの特徴
  15. 15. 本日のアジェンダ 1.日頃の業務開発 1-1.アプリケーションの特徴 1-2.チームの状況 2.環境構築/ライブラリについて 3.どう考えて作っているか 3-1.本日向け開発物の紹介 3-2.React周りの実装について 3-3.Flux周りの実装について
  16. 16. 初期チーム(起ち上げ期) 2人 日頃の業務開発 > チームの状況 わたくし ・基礎設計/開発 ・開発ルール策定 ・機能開発 ・UT設計/開発 ・コードレビュー ・スケジュールマネ ・インフラ調整 ・システム間I/F設計 デザイナー ・要件定義 ・UIイメージ/モック作成 ・機能開発 やるべきことの範囲が広いが、 まだアプリもそこまで複雑ではないし、 殆どのコードに目を通している状態 なので、管理はし易い状態
  17. 17. 七ヶ月後のチーム(拡大期) 4人 日頃の業務開発 > チームの状況 わたくし ・アーキテクチャ改善 ・機能開発 ・UT設計/開発 ・コードレビュー ・新人育成 デザイナー ・要件定義 ・UIイメージ/モック作成 ・機能開発 チーム長(NEW!) ・機能開発 ・コードレビュー ・スケジュールマネ ・インフラ調整 ・システム間I/F設計 若手(NEW!) ・機能開発 やるべきことの範囲は狭まったが コード量や複雑化度合いは増し、 人も増えたのでアンコントローラブル な部分も増えました。
  18. 18. 今年四月以降のチーム(More拡大期) 6〜8人 日頃の業務開発 > チームの状況 わたくし ・アーキテクチャ改善 ・機能開発 ・UT設計/開発 ・コードレビュー ・新人育成 デザイナー ・要件定義 ・UIイメージ/モック作成 ・機能開発 若手 ・機能開発 更に2〜3人JOINの 予定 チーム長 ・機能開発 ・コードレビュー ・スケジュールマネ ・インフラ調整 ・システム間I/F設計 コードの書き手がさらに増え、放った らかしにしておくとカオス状態に成る のが目に見えています。
  19. 19. アプリケーション複雑性が増し 人数も増えていっております。 状況に応じて、開発ポリシーの更新や 技術的なテコ入れをしないと 「アッ」という間にぐちゃぐちゃになる ので常に改善意識が必要です。 日頃の業務開発 > チームの状況
  20. 20. 本日のアジェンダ 1.日頃の業務開発 1-1.アプリケーションの特徴 1-2.チームの状況 2.環境構築/ライブラリについて 3.どう考えて作っているか 3-1.本日向け開発物の紹介 3-2.React周りの実装について 3-3.Flux周りの実装について
  21. 21. どう考えて作っているか > 環境構築/アーキテクチャについて ビルド Gulp経由でwebpackを叩いていますが、 最近はnpm scriptからwebpackを叩くように鞍替えしつつあります。 そのほうがwebpackオプションの痒いところに手がとどくためです。 いまはgulp-webserverが便利なのでGulpを撤廃はしないと思います。 watchビルドはwebpackコマンドを叩いています。 差分ビルドしてくれるのでビルド完了が速いです。 止め
  22. 22. 環境構築/ライブラリについて Webサーバ gulpfile.jsはこれだけで 良いと思ってます。 gulp-webserverの機能としては ・Webサーバ ・LiveReload(JS更新時にブラウザ更新) ・プロキシ機能(Ajaxリクエストを別サーバに捌ける) を使ってます。便利! プロキシのURL周りに変な挙動もあるんですが。 (転送後のURL末尾に/が勝手に付く)
  23. 23. Browser HTML JS Web Server Web App Web Server Ajax通信転送 (Gulp-WebServerのプロキシ) このセットでボチボチ生産性あげています 環境構築/ライブラリについて コード変更 -> Webpackの watchビルド(速い) LiveReloadで自動ブラウザ更新
  24. 24. 環境構築/ライブラリについて エディタ WebStor m Atom Chrome プロダクトコードは 主にコレで書いてます。 メンバー全員使ってます。 無いと辛いです。 ライブラリを使ったりした ちょっとしたコードスニペット 作成に使ってます。 BOMとかネイティブメソッドは Chromeコンソール使ってます。 神補完。
  25. 25. 環境構築/ライブラリについて ライブラリ immutable.js lodash moment constを真にconstたらしめ、脳内デー タフローと現実を合わせるための要に なってます。くわしくは Qiitaにconst周りで記事書いておりま す。 最悪無くても生きていけるんですが 車輪の再発明をしなくて良いよう 使っています。 時間処理系は コレのおかげでだいぶコードが シンプルになっております。
  26. 26. Appフレームワーク 本日のお題であるので当然ですがフレームワークはReactです。 画面遷移についてはReact-Routerを使っています。 おそらくみんなが使っている鉄板だと思います。 PC向けの画面開発はReact-Bootstrapが不足なく使いやすいです。 このUI嫌い!じゃなければおすすめです。 環境構築/ライブラリについて
  27. 27. 本日のアジェンダ 1.日頃の業務開発 1-1.アプリケーションの特徴 1-2.チームの状況 2.環境構築/ライブラリについて 3.どう考えて作っているか 3-1.本日向け開発物の紹介 3-2.React周りの実装について 3-3.Flux周りの実装について
  28. 28. この勉強会の機会を頂いたので 日頃の業務開発の経験を踏まえて アプリを作りました。 これをベースにこの先の話をしたいので、 軽く紹介しておきます。 どう考えて作っているか > 本日向け開発物の紹介
  29. 29. 私的映画鑑賞履歴管理App Movie Logger ともうします どう考えて作っているか> 本日向け開発物の紹介
  30. 30. MovieLoggerのモデル どう考えて作っているか> 本日向け開発物の紹介 1 0...1 0...3 Movie Director Actor 1
  31. 31. 動機 どう考えて作っているか> 本日向け開発物の紹介 ・本日の肴とするために 何かの管理画面を作りたかった ・これまでの改善ノウハウを整理して 今のベストコードをまとめたかった ・幾つかの新しい技術チャレンジをしたかった ・去年から映画にハマりだしたので 役者や監督の顔や名前を覚えたかった ・今年150本鑑賞が目標なので 今なん本なのか知りたかった
  32. 32. 業務開発との技術的な部分の違い どう考えて作っているか> 本日向け開発物の紹介 ・基本はほぼ同じ思想の実践 ・TypeScript・Material-UIを導入 (普段はES6・Bootstrap)
  33. 33. 機能も紹介します。 後でコードや思想を語るために 構造を事前共有したいと思います。 どう考えて作っているか> 本日向け開発物の紹介
  34. 34. 機能紹介(管理対象) どう考えて作っているか> 本日向け開発物の紹介 管理対象オブジェクトは 「映画」「監督」「俳優」の3種です 映画は監督0...1、俳優0...3の多重度で 参照を持つことが出来ます。
  35. 35. 機能紹介(登録/編集) どう考えて作っているか> 本日向け開発物の紹介 タイトルを入れると その文字列から画像検索が出来ます。 監督や俳優は予め登録した人が オートコンプリートで設定出来ます
  36. 36. 機能紹介(一覧) どう考えて作っているか> 本日向け開発物の紹介 アイテム件数を表示してます。 コレで今年何本観たか わかります。 フィルタはプリセットで用意しまし たが、自由度高めると それなりに設計が要りそうです。
  37. 37. 機能紹介(一覧) どう考えて作っているか> 本日向け開発物の紹介 映画アイテムをクリックすると 紐付いてる監督・俳優が パカーと出てきます 横のメニューで 編集ダイアログが立ち上がります
  38. 38. 機能紹介(一覧) どう考えて作っているか> 本日向け開発物の紹介 俳優さん一覧も同じノリです 名前順に並べたら 「でんでん」の存在感が半端ないです 出演作品の中で自分が観た本数や 平均レビュー点数が見れます。 パカっとやると出演作品がでます
  39. 39. 本日のアジェンダ 1.日頃の業務開発 1-1.アプリケーションの特徴 1-2.チームの状況 2.環境構築/ライブラリについて 3.どう考えて作っているか 3-1.本日向け開発物の紹介 3-2.React周りの実装について 3-3.Flux周りの実装について
  40. 40. 人数、機能数共に増加していくと 皆がなるべく同じポリシー/レシピで 作れることが鍵だと思います。 ウチはReact周りでどんなポリシーを 共有しているのかを述べてまいります。 どう考えて作っているか > React周りの実装について
  41. 41. ウチのReactポリシー① Prop/PropTypesはちゃんと定義する。 どう考えて作っているか > React周りの実装について
  42. 42. typescriptの (Movie Loggerの共通コンポーネント) どう考えて作っているか > React周りの実装について React.createClassの React.Componentの 「お外から帰ったら手を洗いなさい」的な話かと思いますが 同じ目的のpropが複数定義されてしまったりがウチではホントにありました。 isRequiredつけておけば警告挙げてくれますし、必ずやるようにしています。 Prop/PropTypesはちゃんと定義する。
  43. 43. ウチのReactポリシー② Stateはしかるべき場所で集中管理。 子コンポーネントは 自分のためのStateだけを持つようにする。 どう考えて作っているか > React周りの実装について
  44. 44. Stateはしかるべき場所で集中管理 どう考えて作っているか > React周りの実装について 例えば右の一覧では4つの Movieインスタンスを管理 しています。
  45. 45. Stateはしかるべき場所で集中管理 どう考えて作っているか > React周りの実装について 一覧から開かれる編集画面はやはり1つの Movieインスタンスを管理します。 ※正確にはpropMovieとstateMovieの2つですが。 ココで、スタローン監督の表示部は 子コンポーネントとなっています。 右のマイナスボタンをクリックすると、 あわれスタローン監督はロッキー3から デタッチされるというシナリオですが、 ここのコードを見てみましょう。
  46. 46. Stateはしかるべき場所で集中管理 どう考えて作っているか > React周りの実装について 親側 子側 ・子側はStateを持たずに親のStateを貰う ・子のボタンがクリックされたら 子が持っている値を使って 親から譲り受けたコールバックを叩く。
  47. 47. Stateはしかるべき場所で集中管理 どう考えて作っているか > React周りの実装について 以前、膨大・複雑かつ複数箇所で使われる コンポーネントに対して、 コード量少なくする目的でにStateもたせたら、 改修が半端じゃなく大変な上、 どこで何やってんのかわけわかんなくなって 滅茶苦茶大変でした。。 失敗から生まれた家訓であります。 親のコードの減らし方は後述します。 今は親のコードが多少増えても 子に状態持たせることに関してはすごい慎重にします。 とは言え、親にとって不要かつ 子が必要な状態は子が持つべきでしょう。
  48. 48. ウチのReactポリシー③ コンポーネント共通化に固執しすぎない。 どう考えて作っているか > React周りの実装について
  49. 49. どう考えて作っているか > React周りの実装について コンポーネント共通化に固執しすぎない。 例えば、さっきの映画編集画面ですが 右のキョンキョンと三浦友和のコンポーネントは あえて別物にしてみてます。 大きな違いは削除ボタンを 持っているかいないかだったりします。 共通化出来そうなので共通化しても良いと思います。 でも、キョンキョンのコンポーネントは候補用なので マッチング度で色変えたいとか、三浦友和のコンポー ネントは確定用なのでアイコン大きくしたいとか異な る要求が降ってくる可能性が考えられます。 となると、とたんにコンポーネント内部の分岐やオプ ションpropが増えてきます。
  50. 50. どう考えて作っているか > React周りの実装について コンポーネント共通化に固執しすぎない。 関数同様、共通化するという行為自体はプログラマにとって 実施すべき大切な行為だと思います。 これはJSコードも同様だと思いますが、共通化するとpropsや分 岐が増えて保守性が下がり、変更に対する柔軟性が失われてしま う可能性があります。 共通化のメリットと同じくらいリスクを見据えて、 見た目は似ていても、本当に同じ目的に対して動作するのもの? という疑問を投げかけるようにしています。
  51. 51. ウチのReactポリシー④ Reactに仕事をさせすぎない。 どう考えて作っているか > React周りの実装について
  52. 52. どう考えて作っているか > React周りの実装について Reactに仕事をさせすぎない ReactはViewに関することは一通り出来るように 機能提供されていると思います。 ソレが故に色んな仕事をさせ過ぎてViewの処理が大 変だった時期がありました。 具体的にはバリデーションと分岐処理です。 次のFlux実装の中のModelクラスについての話でお 話をします。
  53. 53. 本日のアジェンダ 1.日頃の業務開発 1-1.アプリケーションの特徴 1-2.チームの状況 2.環境構築/ライブラリについて 3.どう考えて作っているか 3-1.本日向け開発物の紹介 3-2.React周りの実装について 3-3.Flux周りの実装について
  54. 54. それなりの規模の Reactアプリケーション開発について 語るにはReactよりFluxが本丸かと思います。 Fluxにおけるポリシーは 責務とScopeのチーム内共有を しっかりやることを大事にしてます。 再びウチの現在のポリシーについてお話します。 どう考えて作っているか > Flux周りの実装について
  55. 55. ちなみにReduxとかのいわゆる 「Fluxフレームワーク」 はちゃんと使い込んだことは無いの で あまり詳しくないです。。 facebookのDispatcherを使ってます どう考えて作っているか > Flux周りの実装について
  56. 56. どう考えて作っているか > Flux周りの実装について まず、お馴染みのこの図ですが
  57. 57. どう考えて作っているか > Flux周りの実装について うちではModelを入れています Domain Model
  58. 58. Modelの役割について どう考えて作っているか > Flux周りの実装について
  59. 59. どう考えて作っているか > Flux周りの実装について ★ドメインオブジェクト1個に関するAPI提供 ・コンストラクタ/ファクトリメソッドの提供 ・オブジェクトデータを正しい型で保持 ・セッターメソッドの提供 ・バリデーションメソッドの提供 ・アクション向け送信用オブジェクトの生成 Modelの役割について
  60. 60. どう考えて作っているか > Flux周りの実装について ・Viewのバリデーション周りの処理が煩雑で フォームコンポーネントのコードが 荒れ気味になっていたのを解消したかった。 複数の値の有効かどうかなどを判断して 他の要素のdisable判定等するのに shouldComponentUpdate使ったりして 面倒くさい感じになっていた。 そもそものModel導入の理由1
  61. 61. どう考えて作っているか > Flux周りの実装について そもそものModel導入の理由1 ・映画タイトルの入力必須 ・視聴済みチェックを入れていたら ・視聴年月日が0/4/6桁の 数値入力が必須 ・レビューの点数選択が必須 ・上記が満たされていれば disabled=false ・左記が満たされていなければ disabled=true 映画登録の登録ボタンが有効になる条件
  62. 62. どう考えて作っているか > Flux周りの実装について そもそものModel導入の理由1 モデル側の判定メソッド群 View側はシンプルになりました
  63. 63. どう考えて作っているか > Flux周りの実装について ・Input要素から受け取る型が文字列になるので 文字列 -> 数値の変換を誰がやるのか はっきりさせたかった そもそものModel導入の理由2
  64. 64. どう考えて作っているか > Flux周りの実装について そもそものModel導入の理由2 e.target.valueは数値ではなく数字で渡してくる。 どこからどこまで数値として扱い どこからどこまで数字として扱うべきか・・・? 例
  65. 65. どう考えて作っているか > Flux周りの実装について そもそものModel導入の理由2 Modelインスタンスは正しい型で値を持つという共通認識があれば 値の変換はView側の責務となる (業務開発のモデル側では型判定も入れたりしています)
  66. 66. どう考えて作っているか > Flux周りの実装について ・StoreのAPIが集合に関するものと 個に関するものが混在していたので 責務分担を綺麗にしたかった。 そもそものModel導入の理由3
  67. 67. どう考えて作っているか > Flux周りの実装について そもそものModel導入の理由3 Model導入後、Storeは集合を扱うAPIのみを提供(シンプルになりました)
  68. 68. Modelインスタンスの ライフサイクルについて どう考えて作っているか > Flux周りの実装について
  69. 69. どう考えて作っているか > Flux周りの実装について 一覧画面について Dispatcherから受けとったペイロードから Storeが生成してComponentに提供する。
  70. 70. どう考えて作っているか > Flux周りの実装について 編集画面について 一覧の各アイテムがモデルを1つ 保持しているので、、 props.movieを受け取って state.movieに入れています
  71. 71. どう考えて作っているか > Flux周りの実装について ちなみにモデルはimmutable.jsのRecordを継承していて 値を変更すると新しいインスタンスを返します。 なのでstate.movieを変更しても props.movieが予期せず変更されることはありません。 編集画面について
  72. 72. どう考えて作っているか > Flux周りの実装について フォームコンポーネントの コンストラクタでState向けに生成 次の入力のために登録処理後に初期化 新規追加画面について
  73. 73. 最後にウチのチームにおける 各領域のスコープ/アクセス権 について (チーム内の決め事) どう考えて作っているか > Flux周りの実装について
  74. 74. ・Storeのデータが更新されるのは Dispatcherからペイロードを受け取った時だけ ・外部向けに更新APIは提供せず、Getterだけを提供する ・自身で解決出来ない場合のみ他のストアに問い合わせのみ可能 どう考えて作っているか > Flux周りの実装について Domain Model
  75. 75. ・Actionのメソッドを叩いていいのはViewだけ ・Actionは外部リソースへのアクセスを責務として View/Store/Modelへのアクセスは行わない どう考えて作っているか > Flux周りの実装について Domain Model
  76. 76. ・Modelは他のModelにアクセスしてはいけず、 例外として、自身の属性として他のModelインスタンスと has-a関係にある時だけアクセス可能 どう考えて作っているか > Flux周りの実装について Domain Model
  77. 77. どう考えて作っているか > Flux周りの実装について Domain Model ・ViewはStateとして保持しているModelのみアクセス可能 ・すべての領域にアクセスよいが変更処理を実行出来るのは上記のみ
  78. 78. 本日のコンテンツは以上でございます。 今のところはこんな内容で うまくチーム開発は回っております。 絶対の正解は無いと思いすし、 ウチのチームのルール/ポリシーが 他のチームで機能しない部分も 多々あると思いますが 皆様のチームのお悩み解決の 参考・一助になれれば幸いで御座います。
  79. 79. 積極採用を行っております いっしょにJavaScriptを書きませんか? さいごに

×