State を使って入力に反応する

宣言型 UI と命令型 UI の比較

UI の相互作用を設計する際、おそらくユーザのアクションに応じて UI がどのように変化するかを考えることが多いでしょう。たとえば、ユーザが回答を送信できるフォームを考えてみましょう。

• フォームに何かを入力すると、「Submit」ボタンが有効になります。
• 「Submit」ボタンを押すと、フォームとボタンが無効になり、スピナが表示されます。
• ネットワークリクエストが成功した場合、フォームは非表示になり、「ありがとうございました」というメッセージが表示されます。
• ネットワークリクエストに失敗した場合、エラーメッセージが表示され、フォームが再び使用可能になります。

命令型プログラミングでは、上記はそのまま UI の相互作用の実装法に対応します。今起こったことに応じて UI を操作するための正確な命令を書かなければならないのです。例えば、車の中で隣に乗っている人に、曲がるたびに行き先を指示することを想像してみてください。

彼らはあなたがどこに行きたいか知りません、彼らはただあなたの指示に従うだけです。（そして、もし方向が間違っていたら、あなたは間違った場所に着いてしまいます！）これは命令型と呼ばれます。なぜなら、スピナからボタンまでの各要素に対して、コンピュータに UI の更新を「指示」しなければならないからです。

この命令型 UI プログラミングの例では、フォームは React を使わずに作成されています。ブラウザの DOM を利用するだけです。

UI を命令的に操作することは、単一の例ではうまくいくかもしれませんが、より複雑なシステムでは指数関数的に難しくなります。例えばこのような様々なフォームでいっぱいのページを更新することを想像してみてください。新しい UI 要素や新しい相互作用を追加する場合、既存のすべてのコードを注意深くチェックして、バグ（例えば、何かを表示または非表示にすることを忘れていないか）を確認する必要があります。

React はこの問題を解決するために作られました。

React では、UI を直接操作することはありません。つまり、コンポーネントの有効化、無効化、表示、非表示を直接行うことはありません。代わりに、表示したいものを宣言することで、React が UI を更新する方法を考えてくれるのです。タクシに乗ったとき、どこで曲がるかを正確に伝えるのではなく、どこに行きたいかを運転手に伝えることを思い浮かべてください。運転手はあなたをそこに連れて行くのが仕事ですし、あなたが考えもしなかった近道も知っているかもしれません！

UI を宣言的に考える

上記では、フォームを命令的に実装する方法を見てきました。React で考える方法をより理解するために、以下でこの UI を React で再実装する方法を確認していきます。

1. コンポーネントの様々な視覚状態を特定する
2. それらの状態変更を引き起こすトリガを決定する
3. useStateを使用してメモリ上に state を表現する
4. 必要不可欠でない state 変数をすべて削除する
5. イベントハンドラを接続して state を設定する

Step 1: コンポーネントの様々な視覚状態を特定する

コンピュータサイエンスでは、 「ステートマシン」 がいくつかの「状態」のうちの1つであることを耳にすることがあります。デザイナと一緒に仕事をしていると、さまざまな「視覚状態」のモックアップを見たことがあるかもしれません。React はデザインとコンピュータサイエンスの交点に位置しているため、これら両方のアイデアがインスピレーションの源になります。

まず、ユーザが目にする可能性のある UI の様々な「状態」をすべて可視化する必要があります。

• 未入力：フォームには無効な「送信」ボタンがあります。
• 入力中：フォームには有効な「送信」ボタンがあります。
• 送信中：フォームは完全に無効化されます。スピナが表示されます。
• 成功：フォームの代わりに「ありがとうございました」のメッセージが表示されます。
• エラー：入力中の状態と同じですが、追加のエラーメッセージがあります。

デザイナのように、ロジックを追加する前に様々な状態の「モックアップ」を作成することをお勧めします。例えば、フォームの表示部分だけのモックを以下に示します。このモックはデフォルト値が 'empty' の statusという props によって制御されます。

その props の名前は何でもよくて、命名は重要ではありません。status = 'empty' を status = 'success' に編集して、成功のメッセージが表示されるのを確認してみてください。モックアップを使えば、ロジックを結びつける前に、UI を素早く反復することができます。同じコンポーネントのより具体的なプロトタイプを以下に示しますが、これも status プロパティによって「制御」されています。

import Form from './Form.js';

let statuses = [
  'empty',
  'typing',
  'submitting',
  'success',
  'error',
];

export default function App() {
  return (
    <>
      {statuses.map(status => (
        <section key={status}>
          <h4>Form ({status}):</h4>
          <Form status={status} />
        </section>
      ))}
    </>
  );
}

Step 2: それらの状態変更を引き起こすトリガを決定する

以下の 2 種類の入力に応答して、状態の更新をトリガすることができます。

• Human inputs（人間からの入力）、例えばボタンをクリックする、フィールドに入力する、リンクをナビゲートするなど。
• Computer inputs（コンピュータからの入力）、例えばネットワークからのレスポンスが到着する、タイムアウトが完了する、画像が読み込まれるなど。

いずれの場合も、UI を更新するためには state 変数を設定する必要があります。 今回開発するフォームでは、いくつかの異なる入力に反応して状態を変更する必要があります。

• テキスト入力の変更（人間）は、テキストボックスが空かどうかによって、未入力の状態から入力中の状態に切り替えるか、その逆にする必要があります。
• 送信ボタンのクリック（人間）はそれを送信中の状態に切り替える必要があります。
• 成功したネットワーク応答（コンピュータ）はそれを成功状態に切り替える必要があります。
• ネットワーク応答の失敗（コンピュータ）は、対応するエラーメッセージと共にエラー状態に切り替える必要があります。

このフローを視覚化するために、各状態をラベル付きの円として紙に描き、2 つの状態間の変化を矢印として描くことを試してみてください。このようにして多くのフローを描き出すことで、実装のはるか前にバグを整理することができます。

Step 3: useStateを使用してメモリ上に state を表現する

次に、useState. を使用してコンポーネントの視覚状態をメモリ内で表現する必要があります。シンプルさが鍵です。各 state は「動くパーツ」であり、可能な限り「動くパーツ」を少なくすることが望ましいです。複雑さが増すとバグも増えます！

まず絶対に必要な state から始めます。例えば、入力の答えを保存する必要があり、最後のエラーを保存するために（存在すれば）エラーを保存する必要があります。

const [answer, setAnswer] = useState('');
const [error, setError] = useState(null);

そして、どの視覚を表示させるかを表す state 変数が必要になります。通常、メモリ上でそれを表現する方法は 1 つではないので、実験してみる必要があります。

もし、すぐにベストな方法が思い浮かばない場合は、まず、考えられるすべての視覚状態を確実にカバーできる程度の state を追加することから始めてください。

const [isEmpty, setIsEmpty] = useState(true);
const [isTyping, setIsTyping] = useState(false);
const [isSubmitting, setIsSubmitting] = useState(false);
const [isSuccess, setIsSuccess] = useState(false);
const [isError, setIsError] = useState(false);

最初のアイデアがベストでない可能性もありますが、それはそれで OK です。state のリファクタリングはプロセスの一部です！

Step 4: 必要不可欠でない state 変数をすべて削除する

state の内容に重複がないようにし、本当に必要なものだけを追跡するようにしたいです。state の構造をリファクタリングすることに少し時間をかけることで、コンポーネントが理解しやすくなり、重複が減り、意図しない意味を持つことがなくなります。目標は、メモリ上の state がユーザに見せたい有効な UI を表現していないケースを防ぐことです。（例えば、エラーメッセージを表示すると同時に入力を無効化するようなことはありません。そうすると、ユーザはエラーを修正することができなくなります！）

以下に、state 変数に関する質問をご紹介します。

• この state だと矛盾は生じるのでしょうか？ 例えば、 isTyping と isSubmitting の両方が trueであることはありません。矛盾がある state とは通常、state の制約が十分でないことを意味します。2 つのプール値の組み合わせは 4 通りありますが、有効な state に対応するのは 3 つだけです。「不可能な」 state を削除するためには、これらを組み合わせて、typing、submitting、または success の 3 つの値のうちの 1 つでなければならない status にすればよいです。
• 同じ情報はすでに別の state 変数で利用可能ですか？ もうひとつの矛盾： isEmpty と isTyping は同時に true であることはありません。これらを別々の state 変数にすることで、同期がとれなくなり、バグが発生する危険性があります。幸い、 isEmpty を削除して、変わりに answer.length === 0 をチェックすることができます。
• 別の state 変数の逆数から同じ情報を得ることはできますか？ isError は不要です、なぜなら代わりに error !== null をチェックできるからです。

この削減後、3 つ（7 つから減りました！）の必須 state 変数が残ります。

const [answer, setAnswer] = useState('');
const [error, setError] = useState(null);
const [status, setStatus] = useState('typing'); // 'typing', 'submitting', or 'success'

機能性を壊さない限り、どれかを外すことはできないので、必要不可欠なものであることがわかります。

Step 5: イベントハンドラを接続して state を設定する

最後に、state を更新するイベントハンドラを作成します。以下に、すべてのイベントハンドラが接続された最終的なフォームを示します。

このコードは、元の命令型の例よりも長くなっていますが、はるかに壊れにくくなっています。すべてのインタラクションを state 変化として表現することで、既存の state を壊すことなく、後から新しい視覚状態を導入することができます。また、インタラクション自体のロジックを変更することなく、各 state で表示されるべきものを変更することができます。