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を構築する ↓ 主従関係の逆転の逆転の逆転    ・世界⇨論理(主従関係)    ・論理⇨世界(逆転1)    ・世界⇨論理(逆転2)    ・論理⇨世界<UI>(逆転3)

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] 1コンポーネント内に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