Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Reactの設計概論 ~おてつたびの事例に添えて~
Search
ryubb
January 19, 2022
Programming
1
1.1k
Reactの設計概論 ~おてつたびの事例に添えて~
ryubb
January 19, 2022
Tweet
Share
More Decks by ryubb
See All by ryubb
最近流行りのRemixとは何か
ryubb
1
1.3k
Other Decks in Programming
See All in Programming
Strands Agents で実現する名刺解析アーキテクチャ
omiya0555
1
110
SQLアンチパターン第2版 データベースプログラミングで陥りがちな失敗とその対策 / Intro to SQL Antipatterns 2nd
twada
PRO
35
10k
なぜあなたのオブザーバビリティ導入は頓挫するのか
ryota_hnk
3
520
0から始めるモジュラーモノリス-クリーンなモノリスを目指して
sushi0120
0
170
プロダクトという一杯を作る - プロダクトチームが味の責任を持つまでの煮込み奮闘記
hiliteeternal
0
290
AI Ramen Fight
yusukebe
0
120
No Install CMS戦略 〜 5年先を見据えたフロントエンド開発を考える / no_install_cms
rdlabo
0
380
Understanding Kotlin Multiplatform
l2hyunwoo
0
230
QA x AIエコシステム段階構築作戦
osu
0
220
Gemini CLI のはじめ方
ttnyt8701
1
110
Gemini CLIの"強み"を知る! Gemini CLIとClaude Codeを比較してみた!
kotahisafuru
2
210
Google I/O Extended Incheon 2025 ~ What's new in Android development tools
pluu
1
200
Featured
See All Featured
Writing Fast Ruby
sferik
628
62k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
1k
What's in a price? How to price your products and services
michaelherold
246
12k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.6k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Fireside Chat
paigeccino
37
3.5k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
54k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Thoughts on Productivity
jonyablonski
69
4.8k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Transcript
←マイページ登録 ←Twitter Reactの設計概論 ~おてつたびの事例に添えて~ Presented by 橋本龍之介
←マイページ登録 ←Twitter 自己紹介 橋本龍之介 株式会社おてつたび フルスタックエンジンア エンジニア4年目 ◦使用したことがある言語 PHP, JS,
TS, Java, Python, Ruby ◦使用したことがあるフレームワークやライブラリ FuelPHP, React, Vue, Play Framework, Django, Ruby on Rails ◦その他 ReactとTSが大好き 最近はSwiftに挑戦中
←マイページ登録 ←Twitter useState Redux Recoil Context Class component hooks Functional
component useReducer mobx Containerパターン Atomic Design Compound Components
←マイページ登録 ←Twitter useState Redux Recoil Context Class component state hooks
Functional component state useReducer mobx Containerパターン Atomic Design Compound Components どう設計すれば良いか分からない!
←マイページ登録 ←Twitter 今日話すこと 1. コンポーネント設計 2. State設計 3. Contextの適用箇所
←マイページ登録 ←Twitter 1. コンポーネント設計
←マイページ登録 ←Twitter おてつたびのコンポーネント設計 • Containerパターン • Atomic Design
←マイページ登録 ←Twitter Containerパターンとは Containerパターンとは、責務をロジックとレイアウトに明確に分離して、ロ ジックはContainerコンポーネントに、レイアウトはPresentationalコンポーネ ントにコーディングしていくデザインパータン。 フロントエンドでは、様々な責任を持つコンポーネントが登場するが、一番大 きな分類であるロジックとレイアウトを分離することで、責務の分離とコードの 可読性や保守性を高めるパターン。
←マイページ登録 ←Twitter Containerコンポーネントの責務 1. ビジネスロジック全般 a. onClick等の各種イベントハンドラ b. APIとの通信と副作用の管理 2.
Stateの管理 3. reduxやContextからのデータの受け取り
←マイページ登録 ←Twitter Presentationalコンポーネントの責務 1. HTMLとCSSを用いたレイアウト 2. レイアウトを責務とするコンポーネントの統合 ダイアログやフォームであっても、 state管理は一切行わず、親コンポーネントにあたる Containerコンポーネ
ントで行う。Containerコンポーネントで管理されている stateをpropsで受け取る。
←マイページ登録 ←Twitter Containerパターンを用いたディレクトリ設計 • pageディレクトリの配下に、該当のページ名を表 すディレクトリを作成 上記の例では、記事一覧ページを作成することを 想定しているためArticlesという命名 • Articles配下にContainerコンポーネントである
index.tsxを定義 • Presentatioanlコンポーネントを配置する componentsディレクトリを作成 • Presentatinalコンポーネントを束ねるコンポーネ ント(Atomic Designでいうtemplates)である index.tsxをcomponentsディレクトリ内に定義
←マイページ登録 ←Twitter Atomic Designとは コンポーネントをAtoms、Molecules、Organisms、Templates、Pagesの5つ に責務を分離して設計していくデザイン手法。 PagesはContainerコンポーネントにあたるので、それ以外の4つをレイアウト を責務とするコンポーネントとして設計する。 参考:https://bradfrost.com/blog/post/atomic-web-design/
←マイページ登録 ←Twitter Atomic Designとは その② 各コンポーネントの責務 • Atoms UIの最小単位。 ボタンやフォームの入力フィールド、ラベル単体など
• Molecules Atomsを組み合わせてUIを構成したもの。 入力フィールドとラベルを組み合わせたものや、リストなど • Organisms AtomsやMoleculesを組み合わせてUIを構成したもの ヘッダやサイドバー、フォームなど • Templates 上記のコンポーネントを組み合わせて UIを構成した、ページ全体のUI 実データを渡していないもの • Pages 実データを渡して、実際にページを構成するもの ContainerパターンのContainer componentにあたるので、あまり登場しないコンポーネント
←マイページ登録 ←Twitter Atomic Designベースのディレクトリ設計 • atomsディレクトリ ボタン(Button.sx)などを配置する • moleculesディレクトリ ボタンやラベルを組み合わせたコンポーネント
(Field.tsx)を配置する • organismsディレクトリ atomsやmoleculesを組み合わせたコンポーネン ト(Field.tsx)を配置する • templatesディレクトリ 各ページtemplatesは通常一つしか想定されない ので、index.tsxを作成して、templatesを責務とす るコンポーネントを記載する
←マイページ登録 ←Twitter おてつたびでのコンポーネント設計 • ロジックとレイアウトを分離するためにContainerパターンを導入 • レイアウトの責務の分離は、Atomic Designを意識してコンポーネント設 計を行う •
ある程度コンポーネント数が多いページでは、Atomic Designを用いたコ ンポーネント設計を行う • ディレクトリ設計はContainerパターンは遵守し、Atomic Designを用いる 場合にのみAtomic Designを意識したディレクトリ設計にする
←マイページ登録 ←Twitter • Compound componentsパターンの使用 条件分岐によるViewの宣言を排除し、より宣言的にコーディングするデ ザインパターン • Classコンポーネントでは使用せず、Functionalコンポーネントとhooksで 実装する
• HOCよりRender propsを使用 その他のコンポーネント設計
←マイページ登録 ←Twitter 2. State設計
←マイページ登録 ←Twitter おてつたびのState管理 • useState ◦ ローカルstateの管理 • useReducer ◦
新しく導入しているローカルstateの管理 • Redux ◦ グローバルstateの管理 基本的にはこの3つしか使いません!
←マイページ登録 ←Twitter useStateの例
←マイページ登録 ←Twitter useStateのPros & Cons Pros 1. シンプルで一番分かりやすい 2. シンプルがゆえに、コードが複雑になりづらい
3. パフォーマンスが一番良い Cons 1. 複数のstateを管理する場合、可読性が低下し複雑になりがち 機能の提供が少ないので、可もなく不可もなくと いうような感じ
←マイページ登録 ←Twitter useReducerの例
←マイページ登録 ←Twitter useReducerのPros & Cons Pros 1. 複数の値の管理が行いやすい 2. Reduxのように書くことができる
3. パフォーマンスはそこそこ良い Cons 1. 責務をどこで担当させるかや設計がやや難しい 2. 設計を行わないと、すぐにコードが複雑になる 3. 【個】payloadの型定義がやりづらい
←マイページ登録 ←Twitter reduxのPros & Cons Pros 1. 責務の分離が明確 2. どのコンポーネントからでも容易にデータを渡すことが可能
3. 複数の値を管理でき、namespaceで区切ることも可能 4. ドキュメントやBest practiceなどが豊富 Cons 1. 学習コストが高い(redux, redux-saga, redux-thunk) 2. レンダリングパフォーマンスが悪い 3. 必要ないページで不要なデータを保持してしまう
←マイページ登録 ←Twitter おてつたびでの運用ルール • useState ◦ stateとして管理すべきデータの種類が少なく、複雑な操作を用いないシンプ ルなページ ◦ できれば、userReducerの方を使っていく
• useReducer ◦ stateとして管理すべきデータの種類が多い、もしくは複雑な操作を用いるよ うなページ ◦ 現時点では、積極的に使っていく ▪ どちらかというと、未知なる技術で知見を貯めたいから • Redux ◦ ページ全体に渡って必要なデータを管理する場合のみ使う ▪ 認証やユーザー情報など ◦ まずはuseStateやuseReducerを使う方針で考える ◦ その他グローバルstateで管理することで恩恵を受けられる場合 ▪ APIリクエストを抑制するためのデータ保持など
←マイページ登録 ←Twitter 3. Contextの適用箇所
←マイページ登録 ←Twitter Contextに関して Contextとは • React v16.3で登場した技術 • propsとは別のやり方で、コンポーネント間のデータ授受の機能を提供す る
• stateやデータ管理の機能を提供していない • 比較的シンプルに扱うことができる • コンポーネント間に依存が発生するので、多用は厳禁 state管理機能と組み合わせて使うもので、 propsに近い概念
←マイページ登録 ←Twitter おてつたびでのContext使用例 1. Global state(redux)を使用していない画面 2. 扱うデータの種類が多くて、propsの管理が大変に なる場合 3.
元のソースコードをリファクタする前に一時的に機能 追加する場合 便利なAPIだが、Consumeコンポーネント(Context APIでデータを受け取る側)がProviderコン ポーネントに依存するため、使用箇所は見極めが必要で、基本的には使用しない前提で考えて良 い。 Atomic DesignのTemplatesやOrganismsにあたるコンポーネントはConsumeになって良いが、 MoleculesやAtomsでは依存を避けるためにもConsumeとはならない。
←マイページ登録 Contextはあるコンポーネントに依存する代償としてデータの 受け渡しをシンプルにするという対価を得ているので、その Pros & Consは見極める必要がある。 大前提として、Reduxのように使わないで済む方法を模索 し、どうしてもという場合に依存を最小限にしなければならな い場合以外で使用する
←マイページ登録 ←Twitter 仲間募集中! おてつたびでは、新しい旅の形を一緒に作っていく仲間を募集中です。 募集ポジションは以下の通りです。 • iOSアプリエンジニア • Webフルスタックエンジニア まずはカジュアルにお話ししましょう!
その後、おてつたびに興味を持っていただけたら、是非ご一緒しましょう。 Notion Wantedly iOS Wantedly フルスタックエンジニア
←マイページ登録 ←Twitter SNS SNSもやっています! 今後はZennをメインに発信しつつ、noteやTwitterも活用しています。 フロントエンド中心に発信しているので、興味ある方は閲覧 && フォローをお 願いします! Twitter
Zenn note