背景
仕事でフロントエンドの機能を実装することになったので、利用している React の全体感を知っておくため。最初はプロダクトコードを読んでいたがどうもわからない表現が多くて都度調べるよりか一回包括的に学んだほうがよさそうだと思った。
特に個人開発で Redux を少しやってみた程度、state のバケツリレーはきついというのがわかっている程度だったので耳にはしていた Hooks 周りが全然わからなかった。
メイン担当はバックエンドで、フロントには苦手意識があったが業務でやるくらいしないと勉強できないなと思ってタスクを取ることにした。
React 詳しい人いわく、React がわりと安定してきたのでフロントやるにはいいタイミングだと聞いたのも大きい。
方法
モダンJavaScriptの基本から始める React実践の教科書 をベースに写経やメモを残していった。
リポジトリ
全部写経というより、動かして実感したい Hooks 周りのところはちゃんと書いて動かしていったという感じ。
React の本はたくさん候補があったが
- 出版日ができるだけ近い
- Hooks に触れている
- 評価が高い
で選定した。
所感
前段で書いたとおり、React は Redux で止まっていたが、Hooks の登場でだいぶ開発が楽になったように感じる。
個人的に辛いなと思っていた React というフレームワークを使って開発していくには、React 以外の学習コスト高めのライブラリに頼らないといけないが解消されているように思ったため。Hooks のおかげで、React Tutorial をやれば Component を分割して組み合わせて開発していける。
今回読んだ本は 2021/09 に出版されたものだが、十分今も通用するように感じた。少なくとも、今のプロダクトを触っていくための導入としては申し分ない。
良かったポイントとしては、実際の開発を意識したカスタム Hooks の分割スコープに触れられているところ。この辺を読んで、フロントのロジック共通化は他でも用途が出てきたらでもいいんだなとわかった。
例えば、プロジェクト内で同じAPIを使う関数が複数存在しないように運用ができていればよさそう。
2週間くらい合間を見てフロントエンドをやった自分の理解の範囲では、プロダクトの作り方はこんな感じかと思っている(追加機能開発の場合)
-
開発対象に既存の Component が使いまわせそうか確認する
- ある場合: その Component を一回コピペで持ってきて、動くものを作る
-
動きが実現できたら、必要に応じて Component を共通化できるようにリファクタする
- 利用するComponent が共通 Component の場合は不要。どこかのページで使われているものを持ってきた場合はリファクタする。
- ない場合: 動くものを作る
-
将来的に他でも使うようであれば、チームで相談してComponent の要件を決めて共通Component 置き場に作る
- 該当機能では共通Componentから利用する形にリファクタする
-
StoryBook で動くものを作ってフィードバックをもらう
- StoryBook ないの結構つらいなと感じた。小さく作れないため。作れないと似たような部品が色んなところに散らばる
-
動くものができたら必要に応じてリファクタしていく(ここはまだ試行錯誤中)
- Component に適用される副作用の操作が外から取れるようになっている
-
要は内部で api リクエストをするのが確定していると StoryBook などで使いにくい。部品の単位として API が必要になるのは色々と組み合わせてからが多そう。
- msw などで mock を用意してあげてもいいけど、Component が使う副作用はできるだけないほうがよさそう
- 親の Component が利用する Component の使い方を指示して自由に使えるようになっている。要は利用する Component の振る舞いは Option 指定できるのがよさそう。色々使う側(親Component)で指定できると色んなところで使える。
- 部品化(Component化)する場合はそのComponent が1つのことに専念できているかよく考える。
- 小さければ小さいほど、組み合わせやすいため。使うときに使い方を知るコストが最小限で済む。
- 色んな設定が必要ならそれはもはや Component ではなく Page のようなものになってしまっているのではないか
-
動作の検証パターンを PR に載せる
- エラーケースがカバーできていることを提示する
- react-nativeのPRを参考にした