There is no compression algorithm for experience.

There is no compression algorithm for experience.

Transcript

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