Slide 1
Slide 1 text
There is no compression
algorithm for experience.
小林 京輔
（CTD）
Slide 2
Slide 2 text
table of contents
1. 自己紹介
a. 経歴
2. 美とは何か
a. 荘厳な美について
b. 精緻な美について
3. アーキテクチャ（建築）
a. 高層マンション
b. 壊れた古民家
4. Reactにおける美とは何か
a. Single Responsibility Principle
i. Provider
ii. Custom Hooks
1. Remixパターン
iii. 状態管理
iv. JSX UI、ロジック、スタイル（HTML,JS,CSS）
5. アンチパターンとリファクタリング
6. 責務分離は精緻な美から荘厳な美へと昇華する
a. デコンストラクション（美とは何か）
Slide 3
Slide 3 text
table of contents
1. 自己紹介
a. 経歴
2. 美とは何か
a. 荘厳な美について
b. 精緻な美について
3. アーキテクチャ（建築）
a. 高層マンション
b. 壊れた古民家
4. Reactにおける美とは何か
a. Single Responsibility Principle
i. Provider
ii. Custom Hooks
1. Remixパターン
iii. 状態管理
iv. JSX UI、ロジック、スタイル（HTML,JS,CSS）
5. アンチパターンとリファクタリング
6. 責務分離は精緻な美から荘厳な美へと昇華する
a. デコンストラクション（美とは何か）
Slide 4
Slide 4 text
小林京輔 1996/1/9 (ENTJ)
1. 出身
a. 札幌
2. 生まれ
a. 秋田県能代市
3. 趣味
a. OCTOMORE(スコッチ)
b. React /Remix
c. 西洋哲学・時間論
d. ウィトゲンシュタイン
i. ウィトゲンシュタインハウ
スに行った
ii. 一族の墓にお参りに行った
Slide 5
Slide 5 text
小学生くらい
Slide 6
Slide 6 text
名言っていいこと言ってそう
だけど、矛盾してないか？
Slide 7
Slide 7 text
中学生
Slide 8
Slide 8 text
ショーペンハウエル「読書について」
読書とは（自ら思考せず）他人にものを考えても
らうことである
Slide 9
Slide 9 text
高校生
Slide 10
Slide 10 text
プラトン
完全な三角形は存在しない
Slide 11
Slide 11 text
No content
Slide 12
Slide 12 text
※後にイデア論の話だとわかる
Slide 13
Slide 13 text
大学時代
Slide 14
Slide 14 text
大学時代
Slide 15
Slide 15 text
Ludwig Josef Johann Wittgenstein
Slide 16
Slide 16 text
Only present things exist.
Slide 17
Slide 17 text
現在
過去
知覚の構造
Slide 18
Slide 18 text
パラドックス
Slide 19
Slide 19 text
認識は必然的に過去では？
ならば
認識は過去であるから存在しない？
Slide 20
Slide 20 text
現実性への回帰
Slide 21
Slide 21 text
No content
Slide 22
Slide 22 text
主客二元論への批判
Slide 23
Slide 23 text
社会人
Slide 24
Slide 24 text
経歴
株式会社◼◼◼◼◼ 2018.4~2019.8
＞旅（タイ・台湾）2019.9
株式会社◼◼◼◼ 2019.10~2021.3
＞Reactを楽しむ 2021.4
◼◼◼◼◼◼◼株式会社 2021.5~2022.9
レバレジーズ株式会社 2022.10~
Slide 25
Slide 25 text
株式会社◼◼◼◼◼〜オペレーション部門〜
属人化してた業務の
マニュアル化（怠
惰）
別々で管理されてい
た社内システムを統
合するシステム設計
（怠惰）
SEの友達の家で
Javaの本読む
PC持ってなかったの
でネカフェでプログ
ラミングの勉強
Slide 26
Slide 26 text
株式会社◼◼◼◼◼〜営業〜
見積書100件の作成
をVBAで自動化し手
作業を削減（怠惰）
自動化楽しい・・・
画像を送信したら文
字列で返してくれる
LINEアプリを作る
⇨転職の機運（短気）
（確変）
Slide 27
Slide 27 text
No content
Slide 28
Slide 28 text
株式会社◼◼◼◼（SIer）
Salesforce機能開発
QAチームの業務をGASで
常時監視、ツール作成など
（気づいたらGAS200ファ
イルくらい作ってた）（怠
惰）
⇨もしかしてSIerって
React使わない？（短気）
2020.3
Reactと出会う
※Hooksがメジャー
リリースされて約半
年後
⇨転職の機運（短気）
（確変）
Slide 29
Slide 29 text
No content
Slide 30
Slide 30 text
◼◼◼◼◼◼◼株式会社（コンサルの開発チーム）
自社サービスのフロ
ントエンド担当
（ようやく業務で
React書ける）
⇨俺よりReact詳しく
て書ける人がいない
・・・？（傲慢）
2021.11
Remixと出会う
⇨転職の機運（短気）
（確変）
Slide 31
Slide 31 text
No content
Slide 32
Slide 32 text
レバレジーズ株式会社
HRTech
↓
CTD
SwiftでiOSアプリ
作り始める
Golangを勉強し始め
る
Slide 33
Slide 33 text
table of contents
1. 自己紹介
a. 経歴
2. 美とは何か
a. 荘厳な美について
b. 精緻な美について
3. アーキテクチャ（建築）
a. 高層マンション
b. 壊れた古民家
4. Reactにおける美とは何か
a. Single Responsibility Principle
i. Provider
ii. Custom Hooks
1. Remixパターン
iii. 状態管理
iv. JSX UI、ロジック、スタイル（HTML,JS,CSS）
5. アンチパターンとリファクタリング
6. 責務分離は精緻な美から荘厳な美へと昇華する
a. デコンストラクション（美とは何か）
Slide 34
Slide 34 text
美とは
Slide 35
Slide 35 text
No content
Slide 36
Slide 36 text
1. 私が明証的に真理であると認めるものでなければ、いかなる事柄
でもこれを真なりとして認めないこと
2. 検討しようとする難問をよりよく理解するために、多数の小部分
に分割すること
3. もっとも単純なものからもっとも複雑なものの認識へと至り、先
後のない事物の間に秩序を仮定すること
4. 最後に完全な列挙と、広範な再検討をすること
方法序説
Slide 37
Slide 37 text
No content
Slide 38
Slide 38 text
荘厳な美
Slide 39
Slide 39 text
No content
Slide 40
Slide 40 text
精緻な美
Slide 41
Slide 41 text
No content
Slide 42
Slide 42 text
table of contents
1. 自己紹介
a. 経歴
2. 美とは何か
a. 荘厳な美について
b. 精緻な美について
3. アーキテクチャ（建築）
a. 高層マンション
b. 壊れた古民家
4. Reactにおける美とは何か
a. Single Responsibility Principle
i. Provider
ii. Custom Hooks
1. Remixパターン
iii. 状態管理
iv. JSX UI、ロジック、スタイル（HTML,JS,CSS）
5. アンチパターンとリファクタリング
6. 責務分離は精緻な美から荘厳な美へと昇華する
a. デコンストラクション（美とは何か）
Slide 43
Slide 43 text
高層マンション
Slide 44
Slide 44 text
No content
Slide 45
Slide 45 text
壊れた古民家
Slide 46
Slide 46 text
No content
Slide 47
Slide 47 text
美とは
Slide 48
Slide 48 text
調和？規則性？
Slide 49
Slide 49 text
No content
Slide 50
Slide 50 text
No content
Slide 51
Slide 51 text
プラトン
Slide 52
Slide 52 text
西洋哲学
（人生哲学・経営哲学ではない）
Slide 53
Slide 53 text
自然現象（カオス）を
合理的に説明しようとする
Slide 54
Slide 54 text
世界を論理によって描写する
Slide 55
Slide 55 text
啓蒙主義
Slide 56
Slide 56 text
あれ、なんか香ばしくなってきた
（？）
Slide 57
Slide 57 text
進みます
Slide 58
Slide 58 text
世界
↕
神話↔理性
※「啓蒙の弁証法: 哲学的断想」アドルノ・ホルクハイマー
Slide 59
Slide 59 text
世界
性質：{無秩序・不安・自由}
Slide 60
Slide 60 text
神話の時代
Slide 61
Slide 61 text
物語による説明（伝説）
祈祷
Slide 62
Slide 62 text
理性の時代
Slide 63
Slide 63 text
理性・規律
不自由の自由・科学
Slide 64
Slide 64 text
具象の抽象化
同一化
構造・体系化
意味
Slide 65
Slide 65 text
（無駄に）思考しないために思考する
構造化・体系化・理性
Slide 66
Slide 66 text
カント「純粋理性批判」
Slide 67
Slide 67 text
世界
↕
神話↔理性
Slide 68
Slide 68 text
啓蒙主義時代
Slide 69
Slide 69 text
科学の発展など
Slide 70
Slide 70 text
論理に従って世界がある
↓
主従関係の逆転
Slide 71
Slide 71 text
前提：西洋哲学
Slide 72
Slide 72 text
自由への希求
↓
啓蒙主義への批判・再検討
Slide 73
Slide 73 text
論理に従って世界があるのではなく
世界を論理が描写しているにすぎない
↓
主従関係の逆転の逆転
Slide 74
Slide 74 text
哲学における転回
↓
現象学?・実存主義?
Slide 75
Slide 75 text
自由の回復
↓
アート・文学・詩・創作などなど
Slide 76
Slide 76 text
ん？
Slide 77
Slide 77 text
なんで哲学やってた俺は
React好きなんだろう？
Slide 78
Slide 78 text
具象の抽象化
同一化
構造・体系化
意味
Slide 79
Slide 79 text
コンポーネントっぽい？
Slide 80
Slide 80 text
具象の抽象化
同一化
構造・体系化
意味
Slide 81
Slide 81 text
思考しないために思考する
構造化・体系化
Slide 82
Slide 82 text
UI をインタラクティブにするには、ユーザーが基礎となるデータ モデルを変更できるようにする必要が
あります。これには状態を使用します。
状態は、アプリが記憶する必要がある最小限の変化するデータのセットであると考えてください。状態
を構造化するための最も重要な原則は、状態を DRY (繰り返さない) に保つことです。アプリケーション
が必要とする状態の絶対最小表現を見つけ出し、その他すべてをオンデマンドで計算します。 たとえ
ば、買い物リストを作成している場合、項目を状態の配列として保存できます。リスト内の項目数も表
示したい場合は、項目数を別の状態値として保存せず、代わりに配列の長さを読み取ります。
※Thinking in React(https://react.dev/learn/thinking-in-react#step-3-find-the-minimal-but-complete-representation-of-ui-state)
Slide 83
Slide 83 text
No content
Slide 84
Slide 84 text
「ある事柄を説明するためには、必要以上に
多くを仮定するべきでない」とする指針
オッカムの剃刀
Slide 85
Slide 85 text
論理に従ってUIを構築する
↓
主従関係の逆転の逆転の逆転
・世界⇨論理（主従関係）
・論理⇨世界（逆転１）
・世界⇨論理（逆転２）
・論理⇨世界＜UI＞（逆転３）
Slide 86
Slide 86 text
本編に戻ります
Slide 87
Slide 87 text
table of contents
1. 自己紹介
a. 経歴
2. 美とは何か
a. 荘厳な美について
b. 精緻な美について
3. アーキテクチャ（建築）
a. 高層マンション
b. 壊れた古民家
4. Reactにおける美とは何か
a. Single Responsibility Principle
i. Provider
ii. Custom Hooks
1. Remixパターン
iii. 状態管理
iv. JSX UI、ロジック、スタイル（HTML,JS,CSS）
5. アンチパターンとリファクタリング
6. 責務分離は精緻な美から荘厳な美へと昇華する
a. デコンストラクション（美とは何か）
Slide 88
Slide 88 text
Reactにおける美とは何か
Slide 89
Slide 89 text
Single Responsibility Principle
Slide 90
Slide 90 text
1. Provider
a. 認証・権限は処理をまとめる
2. Custom Hooks
a. Remixパターン
i. loaderとactionを分ける
3. 状態管理
a. 実はURLも状態管理の選択肢
b. レンダリングするならuseState,レンダリングしたくないならuseRef
c. useEffectは極力使わない
i. うまく設計すれば使わなくて良いケースが多々ある
4. JSX UI、ロジック、スタイル（HTML,JS,CSS）
a. HTMLは構造を定義
i. 共通のTemplateファイルを作るのではなく、
HeaderSection,MainContentSectionなどで分けた方が良い
b. JSは処理
i. 関数の分割の粒度、副作用のない設計
c. CSSはスタイル
i. コンポーネント内のみをスタイルし、暗黙的にコンポーネントの外部にス
タイルを当てないこと
Slide 91
Slide 91 text
1. Provider
a. 認証・権限は処理をまとめる
2. Custom Hooks
a. Remixパターン
i. loaderとactionを分ける
3. 状態管理
a. 実はURLも状態管理の選択肢
b. レンダリングするならuseState,レンダリングしたくないならuseRef
c. useEffectは極力使わない
i. うまく設計すれば使わなくて良いケースが多々ある
4. JSX UI、ロジック、スタイル（HTML,JS,CSS）
a. HTMLは構造を定義
i. 共通のTemplateファイルを作るのではなく、
HeaderSection,MainContentSectionなどで分けた方が良い
b. JSは処理
i. 関数の分割の粒度、副作用のない設計
c. CSSはスタイル
i. コンポーネント内のみをスタイルし、暗黙的にコンポーネントの外部にス
タイルを当てないこと
Slide 92
Slide 92 text
認証・権限は処理をまとめる
[Before]
Roterコンポーネントをラップした権限判定するコンポー
ネントをページ数分差し込み
[After]
ルーティングする前に、pathとPermissionMapObjectを
突合してハンドリング
Slide 93
Slide 93 text
1. Provider
a. 認証・権限は処理をまとめる
2. Custom Hooks
a. Remixパターン
i. loaderとactionを分ける
3. 状態管理
a. 実はURLも状態管理の選択肢
b. レンダリングするならuseState,レンダリングしたくないならuseRef
c. useEffectは極力使わない
i. うまく設計すれば使わなくて良いケースが多々ある
4. JSX UI、ロジック、スタイル（HTML,JS,CSS）
a. HTMLは構造を定義
i. 共通のTemplateファイルを作るのではなく、
HeaderSection,MainContentSectionなどで分けた方が良い
b. JSは処理
i. 関数の分割の粒度、副作用のない設計
c. CSSはスタイル
i. コンポーネント内のみをスタイルし、暗黙的にコンポーネントの外部にス
タイルを当てないこと
Slide 94
Slide 94 text
Remixパターン
[Before]
１コンポーネント内にFetchする処理とRequestする処理
が混在
[After]
Fetch用のカスタムHooks、Request用のカスタムHooks
に分ける
Slide 95
Slide 95 text
1. Provider
a. 認証・権限は処理をまとめる
2. Custom Hooks
a. Remixパターン
i. loaderとactionを分ける
3. 状態管理
a. 実はURLも状態管理の選択肢
b. レンダリングするならuseState,レンダリングしたくないならuseRef
c. useEffectは極力使わない
i. うまく設計すれば使わなくて良いケースが多々ある
4. JSX UI、ロジック、スタイル（HTML,JS,CSS）
a. HTMLは構造を定義
i. 共通のTemplateファイルを作るのではなく、
HeaderSection,MainContentSectionなどで分けた方が良い
b. JSは処理
i. 関数の分割の粒度、副作用のない設計
c. CSSはスタイル
i. コンポーネント内のみをスタイルし、暗黙的にコンポーネントの外部にス
タイルを当てないこと
Slide 96
Slide 96 text
実はURLも状態管理の選択肢
[Before]
LocalStorageに保存
[After]
URLに動的Pathとする設計
Slide 97
Slide 97 text
レンダリングするならuseState,レンダリングしたくないならuseRef
[Before]
useStateでフォームの状態を管理
[After]
useRefでフォームの状態を管理
※ただし、escape hatchであることに注意
Slide 98
Slide 98 text
useEffectは極力使わない
ReactDocs
https://react.dev/learn/you-might-not-need-an-effect
Slide 99
Slide 99 text
1. Provider
a. 認証・権限は処理をまとめる
2. Custom Hooks
a. Remixパターン
i. loaderとactionを分ける
3. 状態管理
a. 実はURLも状態管理の選択肢
b. レンダリングするならuseState,レンダリングしたくないならuseRef
c. useEffectは極力使わない
i. うまく設計すれば使わなくて良いケースが多々ある
4. JSX UI、ロジック、スタイル（HTML,JS,CSS）
a. HTMLは構造を定義
i. 共通のTemplateファイルを作るのではなく、
HeaderSection,MainContentSectionなどで分けた方が良い
b. JSは処理
i. 関数の分割の粒度
c. CSSはスタイル
i. コンポーネント内のみをスタイルし、暗黙的にコンポーネントの外部にス
タイルを当てないこと
Slide 100
Slide 100 text
HTML
Slide 101
Slide 101 text
コンポーネントの責務とHTMLの関係
[Before]
画面全体のスタイルを定義するTemplateコンポーネント
[After]
各画面の構造に対応したコンポーネント（Section単位）
Slide 102
Slide 102 text
JS
Slide 103
Slide 103 text
関数の分割の粒度
[Before]
コンポーネント内の変数に依存した関数定義
[After]
受け取った引数で完結する関数
機能ドメインごとに分かれた、過度な共通化がされていな
い関数
Slide 104
Slide 104 text
CSSはスタイル
Slide 105
Slide 105 text
コンポーネントの外部にスタイルを当てないこと
[Before]
子、孫コンポーネントに対してclassNameを使ってスタイ
ルを当てている
[After]
自コンポーネント内のスタイルのみを実装する
Slide 106
Slide 106 text
table of contents
1. 自己紹介
a. 経歴
2. 美とは何か
a. 荘厳な美について
b. 精緻な美について
3. アーキテクチャ（建築）
a. 高層マンション
b. 壊れた古民家
4. Reactにおける美とは何か
a. Single Responsibility Principle
i. Provider
ii. Custom Hooks
1. Remixパターン
iii. 状態管理
iv. JSX UI、ロジック、スタイル（HTML,JS,CSS）
5. アンチパターンとリファクタリング
6. 責務分離は精緻な美から荘厳な美へと昇華する
a. デコンストラクション（美とは何か）
Slide 107
Slide 107 text
アンチパターンとリファクタリング
Slide 108
Slide 108 text
1. 計算できる値を状態として持つ
2. 複数のuseState
3. コンポーネントの内部にコンポーネントを宣言する
4. 子・孫コンポーネントに対してclassNameでStyleを指定す
る
5. AtomicDesignを採用した結果aタグとbuttonタグを内包す
る過度な共通化Button
a. コンポーネントの引数が増える
b. コンポーネント内での条件分岐が発生する
6. 14個のPropsを持つ共通レイアウトコンポーネント
7. KeyのないList
8. 余白を適当につけてしまう
a. 余白も一つの責務
b. Merginの相殺
c. Spacerを導入しよう
Slide 109
Slide 109 text
1. 計算できる値を状態として持つ
2. 複数のuseState
3. コンポーネントの内部にコンポーネントを宣言する
4. 子・孫コンポーネントに対してclassNameでStyleを指定す
る
5. AtomicDesignを採用した結果aタグとbuttonタグを内包す
る過度な共通化Button
a. コンポーネントの引数が増える
b. コンポーネント内での条件分岐が発生する
6. 14個のPropsを持つ共通レイアウトコンポーネント
7. KeyのないList
8. 余白を適当につけてしまう
a. 余白も一つの責務
b. Merginの相殺
c. Spacerを導入しよう
Slide 110
Slide 110 text
「ある事柄を説明するためには、必要以上に
多くを仮定するべきでない」とする指針
Slide 111
Slide 111 text
const [firstName, setFirstName] = useState('');
const [lastName, setLastName] = useState('');
const [fullName, setFullName] = useState('');
Slide 112
Slide 112 text
const [firstName, setFirstName] = useState('');
const [lastName, setLastName] = useState('');
const [fullName, setFullName] = useState('');
Slide 113
Slide 113 text
const [firstName, setFirstName] = useState('');
const [lastName, setLastName] = useState('');
const fullName = useMemo(
() => `${firstName} ${lastName}`, [firstName, lastName]);
Slide 114
Slide 114 text
1. 計算できる値を状態として持つ
2. 複数のuseState
3. コンポーネントの内部にコンポーネントを宣言する
4. 子・孫コンポーネントに対してclassNameでStyleを指定す
る
5. AtomicDesignを採用した結果aタグとbuttonタグを内包す
る過度な共通化Button
a. コンポーネントの引数が増える
b. コンポーネント内での条件分岐が発生する
6. 14個のPropsを持つ共通レイアウトコンポーネント
7. KeyのないList
8. 余白を適当につけてしまう
a. 余白も一つの責務
b. Merginの相殺
c. Spacerを導入しよう
Slide 115
Slide 115 text
const [x, setX] = useState(0);
const [y, setY] = useState(0);
Slide 116
Slide 116 text
const [position, setPosition] = useState(
{ x: 0, y: 0 }
);
Slide 117
Slide 117 text
1. 計算できる値を状態として持つ
2. 複数のuseState
3. コンポーネントの内部にコンポーネントを宣言する
4. 子・孫コンポーネントに対してclassNameでStyleを指定す
る
5. AtomicDesignを採用した結果aタグとbuttonタグを内包す
る過度な共通化Button
a. コンポーネントの引数が増える
b. コンポーネント内での条件分岐が発生する
6. 14個のPropsを持つ共通レイアウトコンポーネント
7. KeyのないList
8. 余白を適当につけてしまう
a. 余白も一つの責務
b. Merginの相殺
c. Spacerを導入しよう
Slide 118
Slide 118 text
開発者体験としての問題
Slide 119
Slide 119 text
読みにくい
Slide 120
Slide 120 text
仮想DOM上の問題
Slide 121
Slide 121 text
状態はツリー内の位置に関連付けられる
Slide 122
Slide 122 text
異なる性質もののが、同一のものとして
判定される位置に存在することが問題
Slide 123
Slide 123 text
import { useState } from 'react';
export default function MyComponent() {
const [counter, setCounter] = useState(0);
function MyTextField() {
const [text, setText] = useState('');
return setText(e.target.value)} />;
}
return (
<>
{
setCounter(counter + 1);
}}
>
Clicked {counter} times
>
);
}
Slide 124
Slide 124 text
1. 計算できる値を状態として持つ
2. 複数のuseState
3. コンポーネントの内部にコンポーネントを宣言する
4. 子・孫コンポーネントに対してclassNameでStyleを指定す
る
5. AtomicDesignを採用した結果aタグとbuttonタグを内包す
る過度な共通化Button
a. コンポーネントの引数が増える
b. コンポーネント内での条件分岐が発生する
6. 14個のPropsを持つ共通レイアウトコンポーネント
7. KeyのないList
8. 余白を適当につけてしまう
a. 余白も一つの責務
b. Merginの相殺
c. Spacerを導入しよう
Slide 125
Slide 125 text
コンポーネントの外部にスタイルを当てないこと
[Before]
子、孫コンポーネントに対してclassNameを使ってスタイ
ルを当てている
[After]
自コンポーネント内のスタイルのみを実装する
再掲
Slide 126
Slide 126 text
1. 計算できる値を状態として持つ
2. 複数のuseState
3. コンポーネントの内部にコンポーネントを宣言する
4. 子・孫コンポーネントに対してclassNameでStyleを指定す
る
5. AtomicDesignを採用した結果aタグとbuttonタグを内包す
る過度な共通化Button
a. コンポーネントの引数が増える
b. コンポーネント内での条件分岐が発生する
6. 14個のPropsを持つ共通レイアウトコンポーネント
7. KeyのないList
8. 余白を適当につけてしまう
a. 余白も一つの責務
b. Merginの相殺
c. Spacerを導入しよう
Slide 127
Slide 127 text
見かけ上同じであることと、コンポーネ
ントの責務・機能において同じであるこ
とは異なる判断指標である
Slide 128
Slide 128 text
コンポーネントの内部で条件分岐してい
るのならば、それは複数の責務を持って
しまっているのでは？
Slide 129
Slide 129 text
1. 計算できる値を状態として持つ
2. 複数のuseState
3. コンポーネントの内部にコンポーネントを宣言する
4. 子・孫コンポーネントに対してclassNameでStyleを指定す
る
5. AtomicDesignを採用した結果aタグとbuttonタグを内包す
る過度な共通化Button
a. コンポーネントの引数が増える
b. コンポーネント内での条件分岐が発生する
6. 14個のPropsを持つ共通レイアウトコンポーネント
7. KeyのないList
8. 余白を適当につけてしまう
a. 余白も一つの責務
b. Merginの相殺
c. Spacerを導入しよう
Slide 130
Slide 130 text
export type BaseContainerProps = Omit & {
className?: string;
title?: string | JSX.Element;
subtitle?: string | JSX.Element;
breadcrumbs?: BreadcrumbContextType[];
isErrorDisplay?: boolean;
expiration?: Date;
containerMt?: string;
headerComponent?: JSX.Element;
headerButton?: JSX.Element;
sideComponent?: JSX.Element;
sidecomponenttop?: string;
mainComponentPb?: string;
mode?: 'list' | 'form';
bottomComponent?: React.ReactChild;
};
Slide 131
Slide 131 text
14個のPropsを持つ共通レイアウトコンポーネント
[Before]
共通レイアウトコンポーネントに引数を渡して表示する
[After]
HeaderSection、MainSectionなどに分け、
Compositionして実装
Slide 132
Slide 132 text
1. 計算できる値を状態として持つ
2. 複数のuseState
3. コンポーネントの内部にコンポーネントを宣言する
4. 子・孫コンポーネントに対してclassNameでStyleを指定す
る
5. AtomicDesignを採用した結果aタグとbuttonタグを内包す
る過度な共通化Button
a. コンポーネントの引数が増える
b. コンポーネント内での条件分岐が発生する
6. 14個のPropsを持つ共通レイアウトコンポーネント
7. KeyのないList
8. 余白を適当につけてしまう
a. 余白も一つの責務
b. Merginの相殺
c. Spacerを導入しよう
Slide 133
Slide 133 text
https://ja.legacy.reactjs.org/docs/lists-and-keys.html
Slide 134
Slide 134 text
1. 計算できる値を状態として持つ
2. 複数のuseState
3. コンポーネントの内部にコンポーネントを宣言する
4. 子・孫コンポーネントに対してclassNameでStyleを指定す
る
5. AtomicDesignを採用した結果aタグとbuttonタグを内包す
る過度な共通化Button
a. コンポーネントの引数が増える
b. コンポーネント内での条件分岐が発生する
6. 14個のPropsを持つ共通レイアウトコンポーネント
7. KeyのないList
8. 余白を適当につけてしまう
a. 余白も一つの責務
b. Merginの相殺
c. Spacerを導入しよう
Slide 135
Slide 135 text
❌
⭕
Slide 136
Slide 136 text
table of contents
1. 自己紹介
a. 経歴
2. 美とは何か
a. 荘厳な美について
b. 精緻な美について
3. アーキテクチャ（建築）
a. 高層マンション
b. 壊れた古民家
4. Reactにおける美とは何か
a. Single Responsibility Principle
i. Provider
ii. Custom Hooks
1. Remixパターン
iii. 状態管理
iv. JSX UI、ロジック、スタイル（HTML,JS,CSS）
5. アンチパターンとリファクタリング
6. 責務分離は精緻な美から荘厳な美へと昇華する
a. デコンストラクション（美とは何か）
Slide 137
Slide 137 text
1. 私が明証的に真理であると認めるものでなければ、いかなる事柄
でもこれを真なりとして認めないこと
2. 検討しようとする難問をよりよく理解するために、多数の小部分
に分割すること
3. もっとも単純なものからもっとも複雑なものの認識へと至り、先
後のない事物の間に秩序を仮定すること
4. 最後に完全な列挙と、広範な再検討をすること
方法序説
Slide 138
Slide 138 text
React is not a framework
(unlike Angular, which is more
opinionated).
ref:https://www.taniarascia.com/getting-started-with-react/
Slide 139
Slide 139 text
Single Responsibility Principle
Slide 140
Slide 140 text
責務分離されることで、結果的にアーキ
テクチャのような調和を持ってフロント
エンドを開発できるのでは？
Slide 141
Slide 141 text
分離された責務
構造化
↓
ソフトウェアアーキテクチャ？
Slide 142
Slide 142 text
There is no compression algorithm
for experience.
経験を圧縮できるアルゴリズムはない
President and Chief Executive Officer
Andy Jassy