Управляемые поля: состояние вместо DOM

У поля ввода в доске задач из части II было две правды. Одна — в объекте состояния, из которого render() собирал разметку. Другая — в свойстве value самого узла, куда браузер складывал нажатые клавиши. Пока форма читалась один раз при отправке, две правды не мешали друг другу. Но стоило показать набранное где-то ещё — в счётчике символов, в подсказке под полем, — приходилось выбирать: либо перечитывать input.value в каждом месте, либо звать render(), который стирал само поле (статья «Зачем React, если вы уже писали рендер из состояния»).

Управляемое поле оставляет одну правду — состояние. Пропс value говорит: «поле показывает эту переменную». Пропс onChange — «когда человек что-то набрал, положи набранное в переменную». Предскажите, что напечатает пример, когда в поле появится слово «кофе»: сколько будет строк «отрисовка» и что окажется в абзаце под полем.

function Search() {
  const [query, setQuery] = React.useState("");
  console.log("отрисовка, query =", JSON.stringify(query));
  return (
    <div>
      <input id="q" value={query} onChange={(e) => setQuery(e.target.value)} placeholder="что ищем" />
      <p id="echo">Ищем: {query}</p>
    </div>
  );
}
ReactDOM.createRoot(document.getElementById("root")!).render(<Search />);

// набираем за читателя «как человек»: исходный сеттер value и событие input.
// Простое el.value = "…" React вводом не считает — почему, во врезке ниже
const typeInto = (id: string, text: string) => {
  const el = document.getElementById(id) as HTMLInputElement;
  Object.getOwnPropertyDescriptor(HTMLInputElement.prototype, "value")!.set!.call(el, text);
  el.dispatchEvent(new Event("input", { bubbles: true }));
};

setTimeout(() => {
  typeInto("q", "кофе");
  console.log("в поле:", (document.getElementById("q") as HTMLInputElement).value);
  console.log("в абзаце:", document.getElementById("echo")!.textContent);
}, 50);

Две отрисовки: при монтировании и после ввода. Круг замкнулся за один проход: событие input из части II дошло до React, тот вызвал onChange, сеттер положил в состояние новый текст, компонент отрисовался заново — и абзац, и поле взяли значение из одной переменной. Ни поиска по DOM, ни второго источника: query — единственное место, где этот текст существует.

value и onChange ходят парой. value без onChange даёт поле, которое нельзя редактировать (раздел ниже); onChange без value — поле, о содержимом которого React не знает. О вторых — следующая статья.

Один символ — одно событие input — один вызов сеттера — одна отрисовка. Значит, слово из четырёх букв, набранное по одной, вызовет компонент четыре раза. Проверим — и заодно посмотрим, что будет, если текст вставить из буфера обмена целиком.

function Search() {
  const [query, setQuery] = React.useState("");
  console.log("отрисовка, query =", JSON.stringify(query));
  return <input id="q" value={query} onChange={(e) => setQuery(e.target.value)} />;
}
ReactDOM.createRoot(document.getElementById("root")!).render(<Search />);

// набираем за читателя: исходный сеттер + событие input, как в первом разделе
const typeInto = (id: string, text: string) => {
  const el = document.getElementById(id) as HTMLInputElement;
  Object.getOwnPropertyDescriptor(HTMLInputElement.prototype, "value")!.set!.call(el, text);
  el.dispatchEvent(new Event("input", { bubbles: true }));
};

setTimeout(() => {
  // четыре нажатия клавиш, по букве за раз
  for (const typed of ["к", "ко", "коф", "кофе"]) typeInto("q", typed);
  console.log("— а теперь вставка из буфера —");
  typeInto("q", "кофе с молоком"); // вставка целиком — как из буфера обмена
}, 50);

Четыре строки на четыре нажатия — и одна на вставку. Считаются не символы, а события: браузер шлёт input на каждое изменение значения, а вставка — одно изменение, сколько бы букв она ни принесла. Обратите внимание и на имя пропса. onChange в React срабатывает на каждое изменение, как DOM-событие input из части II, а не как change, которое ждёт потери фокуса. Имя историческое, и оно сбивает с толку многих; таблица расставляет соответствия.

Отрисовка на каждую букву звучит расточительно, но вспомните, что это такое: вызов функции и сравнение описаний, а в DOM на коммите меняется только то, что отличается (статья «Триггер, рендер, коммит»). Значение поля уже совпадает с состоянием — его React даже не трогает. Дорогим бывает не сам вызов, а то, что вы делаете внутри него на каждую букву, — например, фильтруете тысячу строк. Как не дать такому списку тормозить набор, разбирает статья «Срочное и несрочное: useTransition и useDeferredValue» в главе про скорость.

console.log первой строкой в теле компонента — тот же счётчик отрисовок, что и в главе про состояние: он считает вызовы функции, а не изменения экрана.

В обработчике клика count был снимком отрисовки, а не живой переменной (статья «Состояние — снимок, а не переменная»). Для поля это правило даёт конкретное следствие: в момент, когда вызывается onChange, буква уже в DOM, а в состоянии её ещё нет. Предскажите четыре строки вывода.

function Search() {
  const [query, setQuery] = React.useState("");
  return (
    <input
      id="q"
      value={query}
      onChange={(e) => {
        console.log("в состоянии:", JSON.stringify(query), "| в поле:", JSON.stringify(e.target.value));
        setQuery(e.target.value);
        console.log("после setQuery:", JSON.stringify(query));
      }}
    />
  );
}
ReactDOM.createRoot(document.getElementById("root")!).render(<Search />);

const typeInto = (id: string, text: string) => {
  const el = document.getElementById(id) as HTMLInputElement;
  Object.getOwnPropertyDescriptor(HTMLInputElement.prototype, "value")!.set!.call(el, text);
  el.dispatchEvent(new Event("input", { bubbles: true }));
};

setTimeout(() => {
  typeInto("q", "к");
  typeInto("q", "ко");
}, 50);

e.target.value — текст, который только что появился в узле; query — то, что было в состоянии на момент этой отрисовки. Ни во второй, ни в четвёртой строке query не догнал поле: сеттер планирует следующую отрисовку, а не правит текущую. Отсюда правило: новое значение берётся из события, а не из состояния. Понадобилось тут же проверить длину или подобрать подсказку — проверяйте e.target.value или локальную переменную, в которую вы его положили.

Заметьте, что e.target.value скомпилировался без единого приведения. В статье про обработчики event.target у клика приходилось сужать вручную: там он EventTarget, потому что кликнуть могли по чему угодно внутри кнопки. onChange у <input> получает React.ChangeEvent<HTMLInputElement>, и в этом типе target объявлен как EventTarget & HTMLInputElement: значение меняется у самого поля, другого target у события быть не может. Вынесенной функции, как и в случае с кликом, аннотация нужна явно. Предскажите, что окажется в поле, если набрать «кофе» с тремя пробелами впереди.

function Search() {
  const [query, setQuery] = React.useState("");
  // вынесенная функция: тип параметра выводить неоткуда — аннотируем, как и обработчик клика
  const onChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    setQuery(e.target.value.trimStart());
  };
  return <input id="q" value={query} onChange={onChange} />;
}
ReactDOM.createRoot(document.getElementById("root")!).render(<Search />);

const typeInto = (id: string, text: string) => {
  const el = document.getElementById(id) as HTMLInputElement;
  Object.getOwnPropertyDescriptor(HTMLInputElement.prototype, "value")!.set!.call(el, text);
  el.dispatchEvent(new Event("input", { bubbles: true }));
};

setTimeout(() => {
  typeInto("q", "   кофе");
  console.log(JSON.stringify((document.getElementById("q") as HTMLInputElement).value));
}, 50);

Пробелы пропали из самого поля, хотя в узел они попали: в состояние легла обрезанная строка, отрисовка отдала её в value, и React привёл узел к состоянию. Поле показывает не то, что набрали, а то, что лежит в переменной, — и следующий раздел доводит это наблюдение до конца.

Аннотация строится по той же схеме, что React.MouseEvent<HTMLButtonElement>: React.ChangeEvent<HTMLInputElement> для input, <HTMLTextAreaElement> для textarea, <HTMLSelectElement> для select.

В части II вы выучили, что value у поля — всегда строка, даже у type="number". Управляемое поле сталкивает это правило с типом состояния. Ниже возраст хранится числом, а в сеттер уезжает e.target.value. Перед запуском ответьте на два вопроса: что скажет компилятор и что окажется в подписи «через год», когда в поле наберут 20.

function Age() {
  const [age, setAge] = React.useState(18);
  return (
    <label>
      Возраст:{" "}
      <input id="age" type="number" value={age} onChange={(e) => setAge(e.target.value)} />{" "}
      <span id="next">через год: {age + 1}</span>
    </label>
  );
}
ReactDOM.createRoot(document.getElementById("root")!).render(<Age />);

const typeInto = (id: string, text: string) => {
  const el = document.getElementById(id) as HTMLInputElement;
  Object.getOwnPropertyDescriptor(HTMLInputElement.prototype, "value")!.set!.call(el, text);
  el.dispatchEvent(new Event("input", { bubbles: true }));
};

setTimeout(() => {
  typeInto("age", "20");
  console.log(document.getElementById("next")!.textContent);
}, 50);

Компилятор отказывается: аргумент типа string не годится для SetStateAction<number> — того самого типа сеттера из статьи про useState. А в кадре под примером — «201»: типы стёрты, строка «20» легла в состояние, и age + 1 сработал как склейка строк из части I. В подписи это безобидно, но та же строка вместо числа уедет в расчёт цены или в запрос — и молча.

Чинить можно двумя способами. Первый напрашивается сам: превращать строку в число в обработчике — setAge(Number(e.target.value)). Второй — честно хранить в состоянии то, что лежит в поле, то есть строку, и получать число там, где оно нужно.

function Age() {
  const [age, setAge] = React.useState("18"); // строка — как и value у поля
  const years = Number(age); // число считается при отрисовке, там, где оно нужно
  return (
    <label>
      Возраст:{" "}
      <input id="age" type="number" value={age} onChange={(e) => setAge(e.target.value)} />{" "}
      <span id="next">через год: {age === "" ? "—" : years + 1}</span>
    </label>
  );
}
ReactDOM.createRoot(document.getElementById("root")!).render(<Age />);

const typeInto = (id: string, text: string) => {
  const el = document.getElementById(id) as HTMLInputElement;
  Object.getOwnPropertyDescriptor(HTMLInputElement.prototype, "value")!.set!.call(el, text);
  el.dispatchEvent(new Event("input", { bubbles: true }));
};

setTimeout(() => {
  typeInto("age", "20");
  console.log(document.getElementById("next")!.textContent);
  typeInto("age", ""); // человек стёр всё, чтобы набрать заново
  console.log(document.getElementById("next")!.textContent);
}, 50);

Второй способ скромнее на вид, но переживает всё, что человек может набрать: пустое поле, минус без цифр, недописанное 1e. У числового состояния для таких промежуточных положений нет представления: пустое поле — это не ноль и не NaN, а «ещё не ввели». Отсюда правило: в состоянии управляемого поля лежит то, что лежит в поле, а производные значения считаются при отрисовке — без отдельного состояния и без эффекта (статья «Когда эффект не нужен»).

Теперь можно описать, что React делает после каждого события ввода: вызывает onChange, дожидается отрисовки и сверяет узел с value. Разошлись — записывает в узел то, что в value. Отсюда самый частый вопрос первой недели с React: «почему в моё поле нельзя печатать». Ниже три поля, и в каждое пример набирает текст. Предскажите, что останется в каждом.

function Profile() {
  const [name] = React.useState("Рико");
  const [digits, setDigits] = React.useState("12");
  return (
    <form>
      {/* value есть, onChange нет */}
      <input id="a" value="Рико" />
      {/* onChange есть, но сеттер не вызывает */}
      <input id="b" value={name} onChange={(e) => console.log("b видит:", e.target.value)} />
      {/* сеттер вызывается только для ввода, который нам подходит */}
      <input id="c" value={digits} onChange={(e) => { if (/^\d*$/.test(e.target.value)) setDigits(e.target.value); }} />
    </form>
  );
}
ReactDOM.createRoot(document.getElementById("root")!).render(<Profile />);

const typeInto = (id: string, text: string) => {
  const el = document.getElementById(id) as HTMLInputElement;
  Object.getOwnPropertyDescriptor(HTMLInputElement.prototype, "value")!.set!.call(el, text);
  el.dispatchEvent(new Event("input", { bubbles: true }));
};
const show = (id: string) => console.log(id + ":", (document.getElementById(id) as HTMLInputElement).value);

setTimeout(() => {
  typeInto("a", "Гость");
  show("a");
  typeInto("b", "Гость");
  show("b");
  typeInto("c", "12x");
  show("c");
  typeInto("c", "123");
  show("c");
}, 50);

Первое поле не приняло ни буквы: value есть, а сеттера, который изменил бы состояние, нет — и после каждого события React возвращает «Рико». Второе поле показывает, что дело не в наличии обработчика. onChange вызвался и увидел «Гость», но состояние не поменял, и результат тот же. React не проверяет, написали ли вы обработчик; он проверяет, совпадает ли узел с value. Первой строкой вывода первое поле получило ещё и предупреждение: React советует взять defaultValue или readOnly. Это отладочная сборка — в песочнице стоит именно она; в боевой предупреждения нет, и поле молча не принимает буквы.

Третье поле — та же «заморозка», поставленная на службу. В части II фильтр на лету перезаписывал value прямо в обработчике. Здесь достаточно не звать сеттер, когда ввод не подходит: буква x дошла до узла, состояние осталось «12», и React вернул узел к состоянию. Обработчик решает, что попадёт в правду; поле следует за правдой.

Нужно поле только для чтения — пишите readOnly. Браузер покажет человеку, что править нельзя, а React перестанет ждать onChange и не будет предупреждать.

Если состояние вам не нужно вовсе, а нужно лишь начальное значение — как у атрибута value из части II, — для этого есть defaultValue. О нём, о ref и о том, когда поле лучше оставить браузеру, — следующая статья.

Форма из восьми полей не означает восемь useState. В части II один слушатель на форме различал поля по event.target.name (статья про input и change); в React тот же приём — объект в состоянии и один обработчик, который кладёт значение по ключу name. Ключ вычисляемый — синтаксис из части I; копия вместо правки на месте — правило из статьи про объекты в состоянии. Чекбокс выбивается из ряда: у него правда лежит не в value, а в checked, и управляют им пропсом с тем же именем. Сколько строк «отрисовка» даст этот сценарий?

interface Profile {
  name: string;
  city: string;
  remote: boolean;
}

function ProfileForm() {
  const [profile, setProfile] = React.useState<Profile>({ name: "", city: "", remote: false });
  console.log("отрисовка:", JSON.stringify(profile));

  // один обработчик на все поля: name говорит, какое поле, — как event.target.name в части II
  const onChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    const { name, value, type, checked } = e.target;
    // копия, а не правка на месте — иначе React не заметит изменения
    setProfile({ ...profile, [name]: type === "checkbox" ? checked : value });
  };

  return (
    <form>
      <input id="name" name="name" value={profile.name} onChange={onChange} placeholder="Имя" />
      <input id="city" name="city" value={profile.city} onChange={onChange} placeholder="Город" />
      <label>
        <input id="remote" name="remote" type="checkbox" checked={profile.remote} onChange={onChange} /> удалённо
      </label>
    </form>
  );
}
ReactDOM.createRoot(document.getElementById("root")!).render(<ProfileForm />);

const typeInto = (id: string, text: string) => {
  const el = document.getElementById(id) as HTMLInputElement;
  Object.getOwnPropertyDescriptor(HTMLInputElement.prototype, "value")!.set!.call(el, text);
  el.dispatchEvent(new Event("input", { bubbles: true }));
};

setTimeout(() => {
  typeInto("name", "Рико");
  typeInto("city", "Дубай");
  document.getElementById("remote")!.click(); // чекбокс переключается кликом, как и у человека
}, 50);

Четыре отрисовки на три поля: первая при монтировании, дальше по одной на событие. У чекбокса значение читается из checked, а событие для него React поднимает по клику — галочка переключается мгновенно, ждать нечего. e.target.name компилятор знает как string благодаря тому же EventTarget & HTMLInputElement. А вот совпадает ли этот name с ключом в Profile, он проверить не может: строка есть строка. Опечатка в атрибуте name заведёт в состояние лишнее поле, и ни одна диагностика об этом не скажет.

interface Profile {
  name: string;
  city: string;
}

function ProfileForm() {
  const [profile, setProfile] = React.useState<Profile>({ name: "", city: "" });
  // ключ проверяет компилятор, а не берётся из DOM строкой
  const field = (key: keyof Profile) => (e: React.ChangeEvent<HTMLInputElement>) => {
    setProfile({ ...profile, [key]: e.target.value });
  };
  return (
    <form>
      <input value={profile.name} onChange={field("name")} placeholder="Имя" />
      <input value={profile.city} onChange={field("cty")} placeholder="Город" />
    </form>
  );
}
ReactDOM.createRoot(document.getElementById("root")!).render(<ProfileForm />);

textarea в React — тоже value, а не текст между тегами; select — value на самом select. Оба отступления от HTML сделаны ради одного: у каждого поля ровно один проп-правда.