JSX — это не HTML

В части II вы собирали узлы руками: document.createElement("li"), затем li.className = "item", затем append. JSX не отменяет этот шаг, а прячет его на один уровень глубже: разметку читает компилятор и переписывает её в вызовы функций ещё до того, как код попадёт в браузер.

Проверить это можно, не заглядывая ни в какие внутренности React. Достаточно посмотреть, что лежит в переменной.

const heading = <h1 className="title">Привет</h1>;

console.log(typeof heading);
console.log(heading.type);
console.log(heading.props.children);
console.log(JSON.stringify(heading));

Компилятор превратил строку разметки в вызов React.createElement("h1", { className: "title" }, "Привет"). Имя тега стало первым аргументом, атрибуты собрались в объект props, содержимое уехало в props.children. Возвращается из вызова простой объект — его даже JSON.stringify печатает без труда. Смысл несут три поля: type, key и props. _owner и _store — служебные: их добавляет отладочная сборка React, которая стоит в песочнице, ради своих предупреждений. В боевой сборке их нет, зато там видно "ref":null — след старого API: с React 19 ref передают обычным пропсом, а отладочная сборка это поле от перечисления прячет. И одного поля в выводе нет ни в какой сборке — $$typeof: его значение символ, а символы JSON.stringify пропускает. По этому символу React и отличает настоящий элемент от объекта, который просто похож на него.

const fromJsx = <p className="hint">Подсказка</p>;
const byHand = React.createElement("p", { className: "hint" }, "Подсказка");

console.log(JSON.stringify(fromJsx) === JSON.stringify(byHand));

Элемент — это описание, а не кусок страницы. Пока его не передали в render, в документе не появилось ни одного узла.

Отсюда следует главное свойство JSX, которого у HTML нет: разметка — это выражение. Её можно положить в переменную, вернуть из функции, передать аргументом, сложить в массив. Что можно писать внутри фигурных скобок — тема следующей статьи; пока достаточно помнить, что снаружи это обычное значение.

// Упрощённая модель нового трансформа — чтобы увидеть форму вызова
function jsx(type: string, props: Record<string, unknown>) {
  return { type, props };
}

const heading = jsx("h1", { className: "title", children: "Привет" });
console.log(JSON.stringify(heading));

Раз атрибуты собираются в объект, их имена становятся ключами этого объекта — то есть кодом на JavaScript. Тут и вылезает язык: class и for — зарезервированные слова. React не стал выдумывать новые имена, а взял те, которые вы уже знаете из статьи «Атрибуты и свойства»: у узла DOM эти свойства называются className и htmlFor. По той же логике все составные имена пишутся в camelCase, как свойства DOM.

Прежде чем жать Run, решите две вещи: сколько диагностик выдаст компилятор — и что произойдёт, если нажать на кнопку в кадре.

function Panel() {
  return (
    <div class="panel">
      <button onclick={() => console.log("сработало")}>Нажмите меня</button>
    </div>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<Panel />);

Диагностик две, и обе с готовым ответом: «Свойство "class" не существует… Вы имели в виду "className"?» и такое же про onclick → onClick. А дальше начинается неприятное. Кнопка нарисовалась, выглядит правильно — и на нажатие не отвечает.

Причина в том, что эти две опечатки ведут себя по-разному. Незнакомый пропс React 19 просто ставит атрибутом, поэтому class="panel" в разметке всё-таки оказался и стиль бы применился. А всё, что начинается на on, React разбирает сам и чужого не пропускает: onclick не стал ни обработчиком, ни атрибутом — он исчез.

Без типов такая опечатка не даёт ни ошибки, ни предупреждения в сборке: кнопка просто не работает. Это ровно тот случай, ради которого стоило проходить часть III.

function Panel() {
  return (
    <div className="panel">
      <button onClick={() => console.log("сработало")}>Нажмите меня</button>
    </div>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<Panel />);

Компилятор молчит, а кнопка в кадре печатает «сработало» на каждое нажатие. Разница между двумя примерами — три символа.

Таблицу заучивать не нужно. Правило простое: имя атрибута из HTML переводится в camelCase, кроме data-* и aria-*, — а на остальное компилятор ответит подсказкой «Вы имели в виду…».

Требование «у разметки должен быть один корень» выглядит произволом ровно до того момента, пока не вспомнить, во что превращается JSX. Каждый тег — это вызов функции, а return отдаёт одно значение. Два соседних тега — это два вызова, и вернуть их разом не из чего.

Компилятор на такое ругается. Но, как и все ошибки типов, эта не отменяет выполнение — код всё равно запустится. Что окажется в кадре?

function Two() {
  return (
    <h1>Заголовок</h1>
    <p>Абзац</p>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<Two />);

«Выражения JSX должны иметь один родительский элемент» — и в кадре только абзац. Заголовок исчез бесследно, хотя вы его написали.

function Two() {
  return (React.createElement("h1", null, "Заголовок"),
    React.createElement("p", null, "Абзац"));
}

console.log(Two().type);

Лечится это либо обёрткой — <div>, <section>, что уместно по смыслу, — либо фрагментом, если лишний узел в разметке не нужен. Фрагмент пишется пустой парой скобок и не оставляет в документе ничего.

const box = (
  <>
    <b>раз</b>
    <i>два</i>
  </>
);

console.log(box.type === React.Fragment);
console.log(box.props.children.length);

Пустая форма <>…</> не принимает ни одного пропса. Как только фрагменту понадобится key — в статье про списки, — придётся писать длинную форму <React.Fragment key={id}>.

Разборщик JSX устроен как разборщик XML: у каждого открытого тега обязан быть конец. Привычка писать <br>, <img> и <input> без закрытия пришла из HTML, где браузер держит в голове список пустых элементов. У компилятора такого списка нет — и он честно ищет закрывающий тег дальше по тексту.

Предскажите, что напечатает пример: важно не то, что будет диагностика, а что окажется в детях абзаца.

const line = <p>Первая<br>Вторая</p>;

console.log(JSON.stringify(line.props.children));

Диагностика говорит: «Элемент JSX "br" не содержит соответствующий закрывающий тег». А в выводе видно последствие: слово «Вторая» стало ребёнком <br>, а не соседом. Это не формальная придирка к слешу — разборщик прочитал вашу разметку иначе, чем вы её задумали, и структура получилась другая.

Отрисовать такое к тому же нельзя: React бросит ошибку выполнения, потому что у <br> детей не бывает. Со слешем структура становится той, которую вы имели в виду, — три ребёнка подряд.

const line = (
  <p>
    Первая<br />
    Вторая
  </p>
);

console.log(JSON.stringify(line.props.children));

Самозакрывающаяся форма законна для любого тега: <div /> — это просто пустой div. А вот <div> без пары — всегда ошибка, даже если визуально «и так понятно».

В HTML значение атрибута — всегда строка, даже когда там число или «да/нет». В JSX значение в фигурных скобках — обычное выражение JavaScript со своим настоящим типом. Отсюда два места, где перенесённая вёрстка ведёт себя не так, как ожидалось.

Первое — style. Это не строка с CSS, а объект: ключи в camelCase, значения — то, что положено свойству. Прежде чем запускать, решите, во что превратится padding: 6.

function Badge() {
  return (
    <span style={{ color: "white", background: "crimson", padding: 6, borderRadius: 4 }}>
      12
    </span>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<Badge />);

В кадре получается padding: 6px и border-radius: 4px: числу React сам приписывает пиксели. Исключение — свойства, у которых единиц нет: lineHeight, zIndex, opacity, flexGrow остаются голыми числами. Двойные скобки, которые всех смущают, — это просто объект внутри фигурных скобок значения.

Строку в style передавать нельзя: React бросит ошибку выполнения. В настоящем проекте её поймает компилятор, но в нашей песочнице типы CSS-свойств урезаны, и единственным сигналом будет запуск.

Второе место — логические атрибуты. В HTML флаг включается самим фактом присутствия атрибута, поэтому disabled="false" поле блокирует. В JSX значение живёт по правилам JavaScript.

function Form() {
  return (
    <form>
      <input defaultValue="Кнопка активна?" disabled="false" />
    </form>
  );
}

ReactDOM.createRoot(document.getElementById("root")!).render(<Form />);

Компилятор: «Тип "string" не может быть назначен для типа "boolean | undefined"». А поле в кадре заблокировано — непустая строка истинна, и React выставил атрибут. Правильная запись — disabled={false}: тогда React вообще не поставит атрибут, и поле останется рабочим.

Типичная задача первой недели: верстальщик прислал кусок HTML, его надо вставить в компонент. Вставленный дословно, он почти никогда не компилируется — и хорошо, потому что часть поломок иначе всплыла бы только у пользователя.

Комментарий стоит разобрать отдельно: <!-- --> компилятор не понимает вовсе — это не разметка, а мусор посреди выражения, и пример с ним даже не запустится. Комментарий в JSX — это обычный комментарий JavaScript внутри фигурных скобок, и в дереве от него не остаётся следа.

const card = (
  <div className="card">
    {/* так пишется комментарий внутри разметки */}
    <input id="nick" defaultValue="Рико" />
    <hr />
  </div>
);

console.log(card.props.children.length);

const note = <div dangerouslySetInnerHTML={{ __html: "<b>жирно</b>" }} />;

console.log(note.props.dangerouslySetInnerHTML.__html);

И последнее, что снимает половину вопросов: JSX не понимает ничего, кроме известных ему имён тегов и пропсов. Тег с маленькой буквы он считает элементом DOM и ищет в списке стандартных, а с большой — вашим компонентом. Поэтому <card /> даст «Свойство "card" не существует в типе "JSX.IntrinsicElements"», а <Card /> — то, что вы хотели.