📕
【勉強会メモ】react-nativeの小規模開発でstorybookを使う理由
コンポーネント志向のおさらい
-
https://www.i3design.jp/in-pocket/8854#
- 分割統治と単一責任原則を守ることによって見通しが良くて再利用できるようになる
- Otobankアプリチームのコードレビュールールの根拠はコレ
- ViewComponentとPresentationalComponentを分ける分割パターンを採用している
- (そのうちコードレビュールールも公開したいなぁ)
storybookとは
- ViewComponentのカタログを作るツール
- react-native-webと組み合わせるとネイティブアプリのコンポーネントをweb上で見れたりもする
何が嬉しいのか
動作確認や開発がしやすくなる
- View部分の単体テストの用に使えるのでTDDっぽいことができる
- storybookに登録できないVCは原理原則的に言うと設計が良くない
- とはいえ原理原則だけでは成り立たないのがプロダクト開発なのでいい塩梅が大事
協業がしやすくなる
- デザイナーに作り途中のものを触ってもらえる
- Viewの部分だけを切り出して実装できる
コードの見通しが良くなる
- コンポーネントのディレクトリ設計はよく破綻する
- atomic designは小規模なアプリには大掛かりすぎる / 後から導入できない
- ファイル システムはツリーだが、コードの依存関係はグラフであるため、どれだけ設計しても綺麗に整理はできないという本質的な問題もある
- 作業するのは人間なので設計は絶対に間違えるし、間違えを直す時間が取れないことが多い。
- storybookはコンポーネントが「どのように分割されているか」をみれるようにするツール
- とりあえずビジュアライズされていると「今あるものを探す」ことがやりやすくなる
何がツラいのか
- はまりどころが結構多い / 情報のキャッチアップが大変
- チュートリアル通りにやるとstorybookとアプリの起動コマンドが同じになってしまう
- [アプリのバンドルサイズを大きくしないようにしつ素早く切り替える]のが大変(https://dev.to/dannyhw/how-to-swap-between-react-native-storybook-and-your-app-p3o)
- react-native-webと併用するやり方はなんかではまった(うろ覚え/そのうち追記します)
- チュートリアル通りにやるとstorybookとアプリの起動コマンドが同じになってしまう
Discussion