MVC/MVVMフレームワークの時代
サーバーからViewとしてHTMLを読み込む方式

Java　Structs
Ruby on Rails
Web系以外の開発でもよく見る形式なのでとっつきやすそう。

MVC系とReactなどの違い

React系のようにJSONを返却するほうだとフロント部分の交換が簡単。
モバイルやデスクトップでもバックを流用できる。

メリット

• フロントとバックの分業が簡単
• 疎結合な設計がしやすい
• Web、モバイル、デスクトップでバックを共有できる

デメリット

• 初回読み込みと描画に時間がかかる
• フロントエンドの学習コストが高い
• フロントのコード量が増える

技術要素

• URLとルーティングの管理
• クライアントでのブラウザ履歴管理による繊維
• 非同期データ通信
• Viewレンダリング
• モジュール化されたコードの管理

Reactはフェイスブックが作ったUIライブラリ。
可読性が高いコードとなるように設計されている。

• 仮想DOM
• 宣言的UI
• 単一方向のデータ受け渡し
• コンポーネント指向・関数コンポーネント
• Fluxアーキテクチャとの親和性

状態管理
コンポーネント指向で開発を行い複雑化していくと状態の管理が重要となる。
Redux

SSR
サーバーサイドレンダリング
サーバーでJavascriptを実行しHtmlをフロントに返却する。
Nodeによりサーバー側でJavascriptが実行できるようになったことで実現。

メリット

• サーバーで描画するので早い
• サーバーでコンテンツを生成するのでSPAでは弱かったSEOを向上させることができる

デメリット

• NodeなどのサーバーでのJavascript実行環境が必要
• サーバーの負荷が増える

SSG
静的サイト生成

事前に静的ファイルとして生成してデプロイする仕組み。

Next
React+SSR+SSGができるフレームワーク

結論：めっちゃ便利！

Fluxアーキテクチャ
双方向ではなく短方向にデータを送信する。

コンポーネント設計
モダンフロントエンドの基本的な考え方
UIを再利用可能な部品として設計する

• 再利用が簡単
• グローバルを汚染しない
• 可読性が上がる
• テストが簡単

AtomicDesign
UIをページ単位で関g萎えるのは大きすぎる。
もっと小さい単位、原子の単位で考えるべきといった考え方。

• Atoms：最小単位、これ以上分解
• Molecules：1つ以上のAtomを使っている。検索フォームなど
• organisms：1つ以上のMoleculesを使用している
• templates：organismsを組み合わせて１つの画面として成り立つもの
• pages：Templateにアプリケーションとして動作するデータが注ぎ込まれたもの

Storybook
コンポーネントをカタログ化して管理できるツール
WPFをもうちょっと便利にした余蘊漢字

• コンポーネント設計を強制できる
• UIの確認が簡単
• 開発者間の分業が簡単
• デザイナーとエンジニアの認識整合に便利
• コンポーネントのテストが簡単

モダンなフロントエンド開発には求められることが多く、フルスクラッチで開発することが難しい。
そのためNextやNuxtなど多機能な古スタックフレームワークが必要になった。

型

• インターフェースと暮らす
• Null/Undefined安全
• ジェネリック

デメリット

• コンパイル時間
• 経験者がいないと導入コストが高くなりがち

DOM要素を取得する場合、型推定がうまく動作しない。
アサーションを使用してうまいこと具体的な型を指定する

変数　= 値　as 型

型エイリアス
Typedef的なやつかと思ったら構造体みたいなものっぽい

Interface
思ったのと違う。。。。
ほぼ型エイリアスと同じ機能。
使う側で正しい使い方をしてあげないといけない。
強制力がない。

型エイリアス：オブジェクト
インターフェース：関数インプットや振る舞いの定義を行う。

と思ったらインターフェースいつも通りつかえるんだ、やったー！
オブジェクトに対するIFと関数に対するIF

あとはC#とほぼ同じ

Union型
型の組み合わせ。
NumberかStringで動作する関数

fuction hogehoge(id: number | string)

エイリアス同士を掛け合わせて新たな型を作成できる

Intersection型
複数の型をマージして１つにし、新しい型を生成できる

このあたりがよくわからない。
型を定義して順守することで得た保守性がというか可読性がなくなっちゃうのでは？
どういったけーすで使うのか知りたい。

マージされたクラスやタイプを定義したほうがよい気がしてたけど、
その場合、プロパティ1つ1つに代入が必要になる
Intersectionならそれが不要で生産性が高いと思う。

hoge.id = id
hoge.str = str
hoge.number =number

Type mergehoge = hoge & sub

リテラル型
enum型で同じようなことやってた気がする

never型
決して発生しない値の種類を指定する。
never型に代入すると、コードの網羅性を担保できる。
Swich文などに条件漏れがあった場合、コンパイルエラーとできる。

Optional Chaining
ネストされたオブジェクトのプロパティが存在するかどうかの条件分岐を簡単に記述できる。
？をつける

console. log( user. social?. facebook)
手島 拓也; 吉田 健人; 高林 佳稀. TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発 (p.125). 株式会社技術評論社. Kindle 版. 

Non-null Assertion Operator
Nullとなりえるオブジェクトがある場合、コンパイルエラーとなるが、！をつけることで抑制できる。
こちらは実行時にエラーが発生する。
Optional ChainingはNullチェックのコードが生成されるため、実行時にエラーが発生しない。

型ガード
IF分で型チェックを行うことで推論を確定させる。

インデックス型
オブジェクトのプロパティが可変の場合、まとめて型を定義できる。

ReadOnly
変更不可、ビルド時に値が確定

Unknown
どんな型でも代入できるが、型を安全なUnknown以外に変更しないと関数やプロパティにアクセスできない

型定義ファイル
グローバルマクロとかバリューとかヘッダーみたいなもん。

tsconfig.json
設定ファイル

Prettier
インデントなどコードのフォーマットをそろえる

ESLint
コードの静的解析

JSXでは中かっこ｛｝を使用することでJavaScriptの値を埋め込むことができる

Reactにおいてのコンポーネントは見た目と振る舞いをセットにしたUIの部品単位
コンポーネントは関数やクラスを用いて実装する。現在は関数コンポーネントがはやり。

コンポーネントは大文字から始めるパスカルケースである必要がある。

コンポーネントに外部から値を渡すに葉propsを使用する。コンストラクタとかUI要素に渡すイメージ

propsの中身は子から書き換えることはできない。

htmlではclassNameやhtmlForを使用する。

Propsからの値の取り出し方が微妙に気持ちわるい。

const { content } = props
手島 拓也; 吉田 健人; 高林 佳稀. TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発 (p.169). 株式会社技術評論社. Kindle 版. 

ProviderとConsumer
Providerにデータをなあg氏、Consumerで取得する。

useState
状態を扱う

useReducer
状態を扱う。複雑な状態を扱うことができる

useCallbackとuseMemo
メモ化のフック
メモ化コンポーネントとは、親コンポーネントが再描画されたとしても、メモ化コンポーネントの状態に変更がなければ再描画を行わない

useCallBackは関数をメモ化するためのフック

useEffect
副作用をじっこうするフック
再描画が終わったときや特定のデータが変化したときだけ処理を実行できる。

useLayoutEffect
再描画される前に実行される

useContext
コンテキストから値を参照するためのフック

useref
参照で受け取る。
参照なので変更しても再描画が発生しない

なんかすごい覚えること多そうだけど、結局は再描画するかしないか＞

Refとかそりゃ参照わたしなら変更しても再描画しないと思う。
検知しようないし

StoryBookはすごくいい。
UIドキュメントの自動生成的なことにも使えるし便利

NodeModule間違って削除したら以下で再インストールできる

npm i

npm run devとか動かなくてびっくりした

Next12.2.3で行けそう

これなんなんって思ってたらNextの基本形なのですね
Component, pageProps

function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />;
}

https://nextjs-ja-translation-docs.vercel.app/docs/advanced-features/custom-app

テストフレームワークまで入れた

やり直す