8月31日の夜の雨になり、9月になって肌寒い日々となってしまった
最高気温が10度以上、下がり、朝晩はさらにひんやり、生温かい水道水は冷たくなり、顔を洗いやすくなる。
これだけ気温が下がると、体調がおかしくなりそうです
風邪をひかないように気を付けましょう
でも、9月7日以降は最高気温が徐々に上がりそうですが、8月の猛暑は戻ってこないのは安心します
気温が下がると、夏バテ気味の身体にはよく、夜の睡眠が良く取れますし、眠気が強くなっています
この涼しい時に暑さ疲れの身体をよく休めましょう
9月4日に2回目のワクチン接種
夕方から、注した部位が膨らんで痛くなり、肩が上がらなくなってきています
この日は、眠気が強かったので、午後9時過ぎに就寝
ワクチン接種後はよく身体を休養するのがよさそう
発熱のことも考えて薬は準備済みですが、平熱のままです
6日の朝までは様子見で、自宅でゆっくり過ごします
涼しくなり、猫達は温かいところで寝ています
へそ天はしばらく見ることはなさそう
エアコンと扇風機、5日間電源オフ、電気代の節約になりそう
官房長官としてはよき菅さん
でも1国の総理としては、リーダーシップが不明だった
新型コロナウィルス対策は誰がやっても難しい問題
その中で、説明しながら次々に対策を行えば、もっと、理解されていたであろう
菅総理のあとは、誰が次期総理になっても混迷するであろう
やるべきことをやりやらないことはやらないのが良い
選挙で言えば、４～６月にやるべきであったし
また、経済との両立で大胆な戦略を踏むべきであった
経済を動かすには飲食店の大胆な改装などの支援
医療関係の充実のためにホテルなどの改装
物資輸送などの充実
などやるべきことを行えば、経済と感染拡大の防止を行えたはず
政局は混迷することがあっても、経済は動く
新型コロナ対策後の経済を見るべきだ
国などの補助金を活かして自らの方向性を変えるべきです
関数コンポーネントです。普通の関数と同じく、引数を型づけしてください。
JSXの要素を返せば戻り値は推論されます。
type AppProps = { message: string }; // interfaceでもよい
const App = ({ message }: AppProps) => <div>{message}</div>;
戻り値を型づけする場合には、JSX.Elementです。
正しい値が返されなければ、エラーが示されます。
const App = ({ message }: AppProps): JSX.Element => <div>{message}</div>;
型エイリアスやインタフェースは定めずに、型注釈を直接書き加えても構いません。
型をほかで使わないときは、この方が簡単です。
const App = ({ message }: { message: string }) =>
<div>{message}</div>;
引数と戻り値をそれぞれ定めるのでなく、関数そのものに型づけすることもできます。
useStateフックには、可能なかぎり初期値を与えましょう。そうすれば、状態変数の型は推論されるからです。
const [text, setText] = useState(''); // 初期値を与える
初期値を与えなかったとき、「React: フックで値を定めた要素に制御されたコンポーネントを使うよう警告が出る ー Warning: Changing uncontrolled input」という問題も確認されています。
型を組み合わせたいという場合には、useStateにユニオン型をジェネリックで定めればよいでしょう。
const [id, setId] = useState<string | number>(0);
あるいは、型が定めてあっても、初期値があとの初期化処理で決まるとか、値がない場合としてnullを含めたいということもあるかもしれません。そのときも、ユニオン型でnullを加えてください。
const [user, setUser] = React.useState<IUser | null>(null);
// 初期化処理など
setUser(newUser);
######################################
Genericsの簡単な具体例(関数編)
// number型
function test(arg: number): number {
return arg;
}
// string型
function test2(arg: string): string {
return arg;
}
test(1); //=> 1
test2("文字列"); //=> 文字列
これをGenericsを使用する事で下記のように書く事が可能です。
test<string>の引数はstring型だけ、またtest<number>の引数はnumber型だけが許されるようになります。
function test<T>(arg: T): T {
return arg;
}
test<number>(1); //=> 1
test<string>("文字列"); //=> 文字列
//※ Genericsでも型推論ができるので、引数から型が明示的にわかる場合は省略が可能
test("文字列２"); //=> "文字列２"
######################################
nullは型に含めず、useStateの初期値が決まらないという場合には、型アサーションで逃げる手もあります。
const [user, setUser] = React.useState<IUser>({} as IUser);
// 型 'null' の引数を型 'SetStateAction<IUser>' のパラメーターに割り当てることはできません。
// setUser(null); // nullは認められない
setUser(newUser); // 型に合致した値のみ設定できる
ただし、型アサーションはTypeScriptに値({})の型を偽っているだけだ、ということにご注意ください。状態変数(user)の値を正しく扱うことは、コードの書き手に委ねられるのです。誤ればランタイムエラーになってしまうかもしれません。
useReducerフックを使うには、リデューサの関数が定められていなければなりません。関数に型づけするのは、リデューサが受け取る状態(state)とアクション(action)のふたつの引数です。戻り値の型は推論されます。
type STORE = { count: number };
type ACTIONTYPE =
| { type: 'increment' }
| { type: 'decrement' };
const reducer = (state: STORE, action: ACTIONTYPE) => {
switch (action.type) {
case 'increment':
return { count: state.count + 1 };
case 'decrement':
return { count: state.count - 1 };
default:
return state;
}
};
export default reducer;
すると、useReducerフックを使う側では、とくに型の定めはなくて構いません。
import { useReducer } from 'react';
import reducer from './reducer';
const initialState = { count: 0 };
const Counter = () => {
const [state, dispatch] = useReducer(reducer, initialState);
};
リデューサ関数そのものを、React.Reducerで型づけることもできます。状態(state)とアクション(action)を受け取って、戻り値は状態です。引数の型はジェネリックで与えてください。
import React from 'react';
// const reducer = (state: STORE, action: ACTIONTYPE) => {
const reducer: React.Reducer<STORE, ACTIONTYPE> = (state, action) => {
};
なお、「React + TypeScript: useReducerを使ったカウンターのアプリケーションに型づけする」は、簡単なカウンターの作例をもとに、さらに詳しく解説しました。ご興味がありましたらお読みください。
判別に用いるプロパティが備わった型を複数結ぶと、判別可能なユニオン型(discriminated union)と呼ばれます。
type ACTIONTYPE =
| { type: 'increment' }
| { type: 'decrement' };
判別用のプロパティ値が限定されるため、それ以外の値を弾くことができるのです。
const reducer = (state: STORE, action: ACTIONTYPE) => {
switch (action.type) {
case 'increment':
return { count: state.count + 1 };
case 'decrement':
return { count: state.count - 1 };
// 型 '"reset"' は型 '"increment" | "decrement"' と比較できません。
/* case 'reset': // エラー
return { count: 0 }; */
default:
return state;
}
};
useEffectフックでは、はっきりした型づけより、推論される戻り値の型にご注意ください。たとえば、つぎの例です。
useEffect(
() =>
window.setTimeout(() => console.log('timeout'), 1000)
, []
);
アロー関数式=>の本体に波括弧{}なしに1行で書いた文は、そのまま戻り値になります(「アロー関数」の「関数の本体」参照)。ところが、useEffectのコールバック関数は、戻り値はなし(undefined)にするか、「エフェクトのクリーンアップ」関数でなければなりません。そのため、つぎのようなエラーが示されてしまうのです。
Type 'number' is not assignable to type 'void | Destructor'.
クリーンアップ関数がないときは、useEffectのコールバックから値を返さないように注意してください(本体が1行のときは波かっこ{}で括ります)。
useEffect(
() => {
window.setTimeout(() => console.log('timeout'), 1000)
}
, []
);
useRefフックについて、「React+TypeScript Cheatsheets」には型の定めと初期値の与え方で、3つの例が示されています。currentプロパティが書き替えられるか、null値の代入を認めるかどうかが違いです。
// 読み取り専用。
const nullRef = useRef<number>(null);
// 指定した型の値で書き替えられる。nullは不可。
const nonNullRef = useRef<number>(null!);
// 型指定にnullを含める。
const nullableRef = useRef<number | null>(null);
イベントハンドラのもっとも簡単な定め方は、要素のイベント属性(onChange)に直に書き加えることです。引数のイベント(event)の型は推論されますので、注釈が要りません。
import React, { useState } from 'react';
function App() {
const [text, setText] = useState('');
return (
<div>
<input type="text"
value={text}
onChange={(event) => setText(event.currentTarget.value)}
/>
</div>
);
}
ハンドラ関数(handleChange)を分けて定めると、通常の関数と同じように引数と戻り値を型づけすることになるでしょう(戻り値は推論させても構いません)。
function App() {
const handleChange = (event: React.FormEvent<HTMLInputElement>): void => {
setText(event.currentTarget.value);
};
return (
<div>
<input type="text"
value={text}
// onChange={(event) => setText(event.currentTarget.value)}
onChange={handleChange}
/>
</div>
);
}
さらに、ハンドラ関数そのものを(この場合FormEventHandlerで)型づけることもできます。定められるのは、前の例と同じく引数と戻り値の型です。けれど、それぞれをアラカルトで決めるのでなく、セットにした関数の型で示す方がより明確になります。
function App() {
// const handleChange = (event: React.FormEvent<HTMLInputElement>): void => {
const handleChange: React.FormEventHandler<HTMLInputElement> = (event) => {
}
ReactではUIを構成する要素のことをコンポーネント(Component)と呼びます。
具体的にはボタンやヘッダー、コンテナなどのことです。Reactで開発する利点としてはそれらのUIパーツをそれぞれ細かくコンポーネントに分けておくことで、再描画が必要なものだけに更新を走らせてパフォーマンスをチューニングができます。
ライフサイクルにはまず、大きく分けて3つの期間があります。
それぞれ順に
Mounting、Updating、Unmountingと呼ばれます。
UIにコンポーネントが描画されるまでの準備期間。
使用できるメソッド:
UIにコンポーネントが表示されていて、基本的にユーザーが操作できる期間。
使用できるメソッド:
他のコンポーネントに切り替える前に現在のコンポーネントを破棄するための期間。
使用できるメソッド:
Mounting時
JSXおよびTSXのフォーマットではまず見かけません。JavaScriptでReactを書く場合にstateの初期化やactionのバインドのために使用します。
Mounting時
1度目のrenderが呼ばれた後に1度だけ呼ばれるメソッドです。この時点ではまだUIに表示されていません。データをフェッチしたり、アニメーションやタイマーをセットする場合はここで行います。このメソッドからはDOMが作成されていますが、直接のDOM操作などライフサイクルを外れる処理は原則避けましょう。
Mounting/Updating時
コンポーネントの根幹となる、一番呼ばれるかつ必須のメソッドです。ここに書いてあるコードが実際にUIに現れるものになります。
renderはpropsやstateが更新されるたびに呼ばれるため、ここで直接propsやstateを操作する処理を書いてはいけません。新しい関数を定義するのも避けましょう。そしてAPIのように、propsやstateの値が変わっても結果は冪等であるべきです。
※冪等：べきとうは、大雑把に言って、ある操作を1回行っても複数回行っても結果が同じであることをいう概念です
Updating時
第一引数に1つ前のprops、第二引数に1つ前のstate、第三引数にsnapshot(後述のgetSnapshotBeforeUpdateの返り値)が入ってきますが、必要なければ省略可能です。これもよく呼ばれるメソッドなため、パフォーマンスを低下させるpropsやstateを更新する処理は最低限にしましょう。また、if文や後述のshouldComponentUpdateで無駄な処理を避けることができます。
Unmounting時
現在のコンポーネントを破棄する直前に呼ばれるメソッドで、アニメーションやタイマーを設定していた場合はここで破棄します。そうしないと新しいコンポーネントのサイクルが始まった後も、その分のメモリが開放されないままになってしまいます。ちなみにもうrenderが呼ばれることはないので、ここでpropsやstateを変更しても意味がありません。
Mounting時
これだけはstaticです。第一引数に次のprops、第二引数に前のstateが入ってきます。propsの値によってstateの値を更新したい場合、propsが更新されてrender()が呼ばれる前にstateの更新が必要かどうかをチェックするメソッドです。更新があれば更新後のstate、なければnullを返します。
Updating時
第一引数に次のprops、第二引数に次のstateを持っており、前のpropsやstateの値やアドレスと比較し、変更がなければfalseを、あればtrueを返します。falseが返るとこのあとのrender()は呼ばれず再描画は行われません。PureComponentを使うと自動的にこの比較を行ってくれるため、自分で書くケースは稀ですが要のメソッドです。
Updating時
このメソッドの返り値はcomponentDidUpdateの第三引数に渡ります。具体例に挙げられているようなスクロール位置など、引き継ぎたい値がある場合に使います。
また上記に上げた以外で、エラーをハンドリングしたい場合はcomponentDidCatch()というメソッドが用意されています。
補足として、React v16.2までで使用されていて、現在は使用を控えたほうがいいメソッドもここで上げておきます。古い資料ではこれらの記述がありますが、見かけても読み飛ばしてよいです。
一度だけ呼ばれ、propsが渡されなかった場合に使う値を指定できます。constructorや、TypeScriptではデフォルト値を指定することで解決可能。
Mounting時にまず呼ばれ、描画前にstateを変更するためのメソッド。TypeScriptではstateに初期値を指定できるので特に必要性を感じることはありません。
v16.3以降ではUNSAFE_componentWillMount()に改名されており、v17で完全に削除予定。1回目のrenderが呼ばれる直前に実行されます。
v16.3以降ではUNSAFE_componentWillUpdate()になっており、これもv17から削除予定です。使いたいと思ったら代わりにcomponentDidUpdate()やgetSnapshotBeforeUpdate()を使用すべき。
v16.3以降ではUNSAFE_componentWillReceiveProps()で、v17から削除予定。componentDidUpdate()またはgetDerivedStateFromProps()で代用できます。
簡単なデザインと、JSONデータを準備する。
設計書もよいが、テスト駆動型でかつアジャイルで開発するほうが、よりよいものができる
モックを形作っている各コンポーネント（構成要素）を四角で囲んで、それぞれに名前をつけていくことです。
JSON のデータモデルをユーザに向けて表示することはよくありますので、モデルを正しく構築されていれば、UI（つまりコンポーネントの構造）にもうまくマッピングされるということが分かるでしょう。これは、UI とデータモデルが同じ 情報の構造 を持つ傾向があるためです。UI を分割して、それぞれのコンポーネントがデータモデルの厳密に一部分だけを表現するよう、落とし込みましょう。
5 種類のコンポーネントがこのアプリの中にあることが見て取れます。
ProductTable を見てみると、表のヘッダ（「Name」や「Price」のラベルを含む）が単独のコンポーネントになっていないことがわかります。
これは好みの問題で、コンポーネントにするかしないかは両論あります。今回の例でいえば、ヘッダを ProductTable の一部にしたのは、データの集合を描画するという ProductTable の責務の一環として適切だったからです。
しかしながら、将来ヘッダーが肥大化して複雑になった場合（例えばソート機能を追加した場合など）は、ProductTableHeader のようなコンポーネントにするのが適切になるでしょう。
さて、モック内にコンポーネントを特定できましたので、階層構造に並べてみましょう。モックで他のコンポーネントの中にあるコンポーネントを、階層構造でも子要素として配置すればいいのです。次のようになります。
データモデルを描画するだけの機能を持った静的なバージョンのアプリを作る際には、他のコンポーネントを再利用しつつそれらに props を通じてデータを渡す形で、自分のコンポーネントを組み上げます。
props は親から子へとデータを渡すための手段です。
state はユーザ操作や時間経過などで動的に変化するデータを扱うために確保されている機能です。今回のアプリは静的なバージョンなので、state は必要ありません。
コンポーネントはトップダウンで作っても、ボトムアップで作っても問題ありません。
つまり、高い階層にあるコンポーネント（例えば FilterableProductTable）から作り始めても、低い階層にあるコンポーネント（ProductRow など）から作り始めても、どちらでもいいのです。シンプルなアプリでは通常トップダウンで作った方が楽ですが、大きなプロジェクトでは開発をしながらテストを書き、ボトムアップで進める方がより簡単です。
ここまでのステップを終えると、データモデルを描画する再利用可能なコンポーネントのライブラリが手に入ります。このアプリは静的なバージョンなので、コンポーネントは render() メソッドだけを持つことになります。
階層構造の中で最上位のコンポーネント（FilterableProductTable）が、データモデルを props として受け取ることになるでしょう。元となるデータモデルを更新して再度 ReactDOM.render() を呼び出すと、UI が更新されることになります。このやり方なら、複雑なことをしていないので、UI がどのように更新されて、どこを変更すればよいか、理解できることでしょう。React の単方向データフロー（あるいは単方向バインディング）により、すべてがモジュール化された高速な状態で保たれます。
UI をインタラクティブなものにするためには元となっているデータモデルを更新できる必要があります。これは React なら state を使うことで実現できます。
適切に開発を進めていくにあたり、そのアプリに求められている更新可能な状態の最小構成を、最初に考えておいたほうがよいでしょう。
ここで重要なのは、DRY (don’t repeat yourself)の原則です。アプリケーションが必要としている最小限の状態を把握しておき、他に必要なものが出てきたら、そのとき計算すればよいのです。
例えば、TODO リストを作る場合、TODO の各項目を配列で保持するだけにし、個数のカウント用に別の state 変数を持たないようにします。その代わりに、TODO の項目数を表示したいのであれば、配列の length を使えばよいのです。
今回は、次のようなデータがあるとする
それぞれについて見ていき、どれが state になりうるのかを考えてみます。
各データについて、考えましょう。
というわけで、state と呼べるのは次の 2 つです。
アプリの各 state について、次の各項目を確認していきます。
それでは、例に適用してみましょう。
state を FilterableProductTable の中に配置することが決まりました。では早速、インスタンス変数として this.state = {filterText: '', inStockOnly: false} を FilterableProductTable の constructor に追加して、初期状態をアプリに反映しましょう。その次は、filterText と inStockOnly を ProductTable と SearchBar に props として渡します。最後に、これらの props を使って ProductTable のフィルタ処理を行い、SearchBar のフォームにも値を埋めます。
現在のバージョンのサンプルで文字を打ち込んだり、チェックボックスを切り替えてみると、React がその入力を無視することがわかります。これは意図的な挙動で、input の value props が、常に FilterableProductTable から渡された state と同じ値になるようにセットしてあるのです。
それでは、どんな挙動になってほしいのかを考えてみましょう。ユーザがフォームを変更するたびに、ユーザ入力を反映するように state を更新したいですね。コンポーネントの state を更新できるのは自分自身だけであるべきなので、FilterableProductTable は SearchBar にコールバックを渡しておいて、state を更新したいときに実行してもらうようにします。入力のたびに呼び出される onChange イベントを利用するとよいでしょう。このコールバックを実行された FilterableProductTable は、setState() を呼び出し、その結果としてアプリが更新されます。