LT&ディスカッション5ラウンド！うひょさん・よしこさんと改めて考えるReactコンポーネント設計

ご質問はzoomの Q&Aボタンよりお送りください質問募集中 ※ 匿名でのご質問も可能です 2023.11.06「LT&ディスカッション5ラウンド！うひょさん‧よしこさんと改めて考えるReactコンポーネント設計」実況はこちら #Oﬀers_Reactコンポーネ
ント設計で投稿しよう！ 2 はじめに 02 コンポーネント設計 LT＆ディスカッションテーマ① 「分割粒度」 03 04 05 質疑応答 01 Agenda コンポーネント設計 LT＆ディスカッションテーマ② 「構造」コンポーネント設計 LT＆ディスカッションテーマ③ 「スタイリング」コンポーネント設計 LT＆ディスカッションテーマ④ 「テスト」コンポーネント設計 LT＆ディスカッションテーマ⑤ 「パフォーマンス」 06 07

ント設計で投稿しよう！ 3 Moderator 佐藤歩株式会社overﬂow VPoE @ahomu 株式会社 overﬂow VPoE として開発組織のマネジメントに携わる。前職の株式会社 CyberAgent では技術⼈事、EM、新規サービス開発などを歴任。 Web フロントエンド技術が専⾨で、著書に「超速！Web ページ速度改善ガイド (共著)」など。ほか複数社の技術顧問‧組織アドバイザーも務める。

ント設計で投稿しよう！ 4 よしこ⽒株式会社ナレッジワークフロントエンドエンジニア @yoshiko_pg 2015年、株式会社グッドパッチ⼊社。 2017年、株式会社FOLIO⼊社。 2020年、株式会社ナレッジワーク共同創業。現在は同社の専⾨役員Principalとしてフロントエンドエンジニア職に従事。 Google Developer Experts。著書『HTML5/CSS3モダンコーディング』登壇者

ント設計で投稿しよう！ 5 うひょ⽒株式会社バベルプリンシパルエンジニア @uhyo_ 2019年に新卒にてLINE株式会社に⼊社。 2022年1⽉より株式会社バベルの技術顧問に就任、同年10 ⽉に正社員として⼊社。現在プリンシパルエンジニアとしてアプリケーションの開発‧設計を担当。著書『プロを⽬指す⼈のためのTypeScript⼊⾨』登壇者

ント設計で投稿しよう！ 01 6 コンポーネント設計 LT＆ディスカッションテーマ① 「分割粒度」

ント設計で投稿しよう！ 7 LT①「分割粒度」よしこ⽒ page model ui 何らかのdomain modelに関連（UserList, GroupPickerなど） domain modelの知識を持つ UIライブラリとして切り出せる汎⽤Component domain modelの知識はないページのentrypointファイルと 1対1で対応するページ実体 domain modelの知識を持つ https://zenn.dev/knowledgework/articles/99f8047555f700 ＼詳しくはこちら／ Componentファイル構成 Button/ ├─ Button.tsx ├─ Button.module.css ├─ Button.stories.tsx └─ index.ts scaﬀdogでつくるよ！ pageとmodelの間に、「domain modelの知識を持ちうる共通Component」のレイヤーが要ると思ってるがまだ作れてない。例：共通ページヘッダ、共通サイドバーなど

ント設計で投稿しよう！ 8 LT①「分割粒度」うひょ⽒ 1ロジック1コンポーネントが良い感じ複数ロジックが同居すると急に⾒通しが悪くなるため。ロジックコンポーネントたち＋まとめコンポーネントの構成が基本。 UIコンポーネントは共通化されたデザインの場合に発⽣する印象。その場限りの場合はあまり分けない。 UIコンポーネントを作る場合も 1つのロジック＝1つの責務を意識。 QRコード表⽰コンポーネント Q&Aボタンコンポーネント（押すと何か起こる想定）サイドバーコンポーネント

ント設計で投稿しよう！ 02 9 コンポーネント設計 LT＆ディスカッションテーマ② 「構造」

ント設計で投稿しよう！ 10 LT②「構造」よしこ⽒あまり⼯夫せず、かなり素朴にそのまま書いてます。分けるとしたら1Component内のコード分割よりも、Componentそのものの分割のほうをマメにやりがちかも⾃分の傾向として、⼤枠の設計や共通部品に⽐べて、局所的なComponentの書き⽅は改善できる点が多そうやってないこと • Container/Presentationパターン • 単⼀Component内でのhooksの抜き出し（複数から利⽤する際に初めて抜きだす）やっててよかったこと • レイヤー間の依存ルールの整理と強制 • 外部ライブラリに依存する際のhooks化や腐敗防⽌層の作成やってて学びがあったこと • render propsは不評だった • Componentディレクトリは全部フラットじゃなくて初⼿は⼊れ⼦のほうがスケールしたとき楽おさらい：Componentファイル構成 Button/ ├─ Button.tsx ├─ Button.module.css ├─ Button.stories.tsx └─ index.ts

ント設計で投稿しよう！ 11 LT②「構造」うひょ⽒ 1コンポーネント1フックが好きコンポーネントのロジック部分を抜き出して隣に置くことで、ロジックのアウトプットが明確になる。ロジックの中間状態を全部JSXから参照されたりすると将来的に wow なことになりがち。 const QRCode = () => { const { imageUrl } = useQRCodeLogic(); return <img src={imageUrl} … />; }; const useQRCode = () => { const imageUrl = use(...); return { imageUrl, element: <QRCode imageUrl={imageUrl} … /> }; }; コンポーネントとフックの依存関係を逆にするとrender hooksパターンになる

ント設計で投稿しよう！ 03 12 コンポーネント設計 LT＆ディスカッションテーマ③ 「スタイリング」

ント設計で投稿しよう！ 13 LT③「スタイリング」よしこ⽒ CSS Modules ⼤好き。⼩回りがきくし潰しもきくから（CSS好き奴のポジショントークであることは否めない）やっていてよかったこと • stylelintでプロパティの並び順やコーディングルールをautofix • typed-css-modulesをCI上でだけ回してセレクタ参照チェック • スタイルだけの再利⽤でもCSS単位での再利⽤を許さず、必ずComponent化して再利⽤する ◦ marginだけは外からあてないといけないので ={margin.top8} のように使えるhelperがある • figmaにもComponentsというファイルを作ってもらい、UI Componentと1:1になるよう同期管理 ◦ Custom Propertiesとfigma側の⾊名なども同様やっておけばよかったこと • レイアウト系のUI Componentをもっと早くから充実させておけばよかった ◦ やっぱり <Flex direction=”column”> みたいになるもの…？

ント設計で投稿しよう！ 14 LT③「スタイリング」うひょ⽒暗黙の依存関係は避けたい親コンポーネントが display: flex; を持ち⼦コンポーネントが flex: 1; を持ってるのは避けたい。セットで書かれるスタイルはなるべく同じコンポーネントに詰め込む。いわゆるCSS Modulesが好き CSSの構⽂が直接使えるのはやっぱり偉い。パフォーマンスも基本的には良好。マージン持ったコンポーネントはあかんで親コンポーネントのための実装が⼦コンポーネントに存在してる状態なのでだめ。 const TwoColumn = ({ left, right }) => ( <div style=”display: flex”> <div style=”flex: 0 1 auto”>{left}</div> <div style=”flex: 1 1 auto”>{right}</div> </div> ); こういうイメージ

ント設計で投稿しよう！ 04 15 コンポーネント設計 LT＆ディスカッションテーマ④ 「テスト」

ント設計で投稿しよう！ 16 LT④「テスト」よしこ⽒ Testing Trophy うち Static Visual Regression End to End Unit Integration ここ強い⽅！お待ちしてます！！ Playwrightで全CRUD 1⽇1回⾃動で回る reg-suitでPRごとカバレッジ⾼誤検出低減がんばってるあんまりできてない Componentはどこテストすべき？ repository, usecase, selectorあたりやってるが本質的でない気がする型も含め結構ガチガチ基本ここのチェック通れば⼀定の安⼼感

ント設計で投稿しよう！ 17 LT④「テスト」うひょ⽒基本はフックに対するユニットテストやはりロジックに関するテストの需要が⼤きいため。 DOM (jsdom) を経由させてもあまり価値が上がらない印象。実際のUIの挙動を検査するなら、ブラウザを動かしちゃった⽅が価値が出そう。 const QRCode = () => { const imageUrl = useQRCodeLogic(); return <img src={imageUrl} … />; }; これをテストする RSCではもはやフックですらなくなるため、さらにテストが簡単になるか。

ント設計で投稿しよう！ 05 18 コンポーネント設計 LT＆ディスカッションテーマ⑤ 「パフォーマンス」

ント設計で投稿しよう！ 19 LT⑤「パフォーマンス」よしこ⽒やってないこと • バンドルサイズのカリカリのチューニング ◦ SaaSでツールなので、ここ頑張るより認証解決速度上げたほうが体感ぐんと変わる印象 ◦ たまに @next/bundle-analyzer ⾒て過剰なものを調整する程度 • Component内でのuseMemo/useCallbackの徹底 ◦ これはパフォーマンス以外にもReact wayに乗れることやスコープの明⽰という側⾯あるのでその意味でも早めに慣れて最初からやっておいたらよかったなーやっててよかったこと • Next.jsの採⽤（ページごとにバンドルを分割） • CSS Modulesの採⽤（Zero Runtime） • Custom Hooksでの返り値のuseMemo/useCallbackの徹底（これ強制できるlintありますか？）別観点でやっておくといいこと • リストのAPI/UIには基本ページネーションをいれておく • ⼀覧表⽰される画像の最適化、動画のサムネイル画像化

ント設計で投稿しよう！ 20 LT⑤「パフォーマンス」うひょ⽒コンポーネント分割とSuspense コンポーネントを適切に分けて出せるUIをなるはやで出すのが何だかんだで⼀番有効。バンドルサイズの削減という意味もあるが、ネットワークの往復数を削減することが⼀番重要。 useMemoはちゃんと使う重い計算を避けるというより、同じオブジェクトを同じままにする最適化‧設計意図の明⽰という意味が⼤きい。（React Forget的なやつが来たら変わるかも？）

ント設計で投稿しよう！ 21 よしこからのお知らせ：ナレッジワーク、エンジニア積極募集こんな⽅々におすすめ！ • 優秀なPdM/Designerと背中を合わせてプロダクト開発の技術⾯をリードしたい⽅ • シニアな先輩の背中を追いかけながら綺麗なコードを吸収して最速成⻑したい⽅ • 複数プロダクトを⽀える共通基盤や仕組みの開発が好きな⽅ • 技術だけでなく事業や組織の成功に関⼼のある⽅、その成功を⾒てみたい⽅ https://kwork.studio/recruit-engineer もしくは yoshikoのXにDMください！

ント設計で投稿しよう！ 22 うひょからのお知らせ：バベルもエンジニア募集中 https://jobs.babel.jp/ セールスイネーブルメント分野のSaaSを提供。トランスパイルにBabelではなくSWCを使っているというウワサだ。プロダクトの成⻑を技術で⽀えたい⼈におすすめ。

LT&ディスカッション5ラウンド！うひょさん・よしこさんと改めて考えるReactコンポーネント設計

LT&ディスカッション5ラウンド！うひょさん・よしこさんと改めて考えるReactコンポーネント設計

Fumina Chihama

More Decks by Fumina Chihama

Featured

Transcript