Ментальные модели React: подходы к мышлению в духе Dan Abramov

Почему React кажется сложным, пока у вас нет нужных ментальных моделей

React может раздражать сначала, потому что вы видите, как UI меняется, но не всегда можете объяснить, почему это произошло. Вы нажимаете кнопку, что‑то обновляется, а потом другая часть страницы вас удивляет. Обычно это не значит «React странный». Это значит «моя картина того, что делает React, расплывчата».

Ментальная модель — это простая история, которую вы рассказываете себе о том, как что‑то работает. Если история неверна, вы будете уверенно принимать решения, которые приводят к запутанным результатам. Подумайте о термостате: плохая модель — «я ставлю 22°C, и комната сразу становится 22°C». Лучшая модель — «я задаю цель, и обогреватель включает/выключает нагрев, чтобы достичь её со временем». С лучшей историей поведение перестаёт казаться случайным.

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

Dan Abramov помог популяризировать такой подход «сделай это предсказуемым». Цель не в том, чтобы заучить правила, а в том, чтобы держать в голове небольшой набор истин, чтобы отлаживать, рассуждая, а не методом проб и ошибок.

Имейте в виду эти идеи:

• UI — результат состояния, а не набор ручных правок DOM.
• Компоненты — это функции, описывающие, как должен выглядеть интерфейс.
• Данные текут вниз; изменения поднимаются вверх через события.
• Сайд‑эфекты отделены от рендера и служат конкретной цели.

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

Компоненты, props и state: основная картина

React становится проще, когда вы перестаёте думать в терминах «экранов» и начинаете мыслить малыми кусочками. Компонент — это переиспользуемая единица UI. Он принимает входы и возвращает описание того, как UI должен выглядеть для этих входов.

Полезно думать о компоненте как о чистом описании: «при данных X показываем Y». Такое описание можно использовать в разных местах, потому что оно не зависит от того, где живёт компонент.

Props — это входы. Они приходят от родителя. Props не «принадлежат» компоненту, и компонент не должен тихо их менять. Если кнопке передали label="Save", задача кнопки — отрисовать эту метку, а не решать, что она должна быть другой.

State — это принадлежащие данные. Это то, что компонент запоминает во времени. State меняется, когда пользователь взаимодействует, когда завершается запрос или когда вы принимаете решение изменить что‑то. В отличие от props, state принадлежит этому компоненту (или тому компоненту, который вы выбрали владельцем).

Короткая версия ключевой идеи: UI — функция от state. Если state говорит «loading», показывайте спиннер. Если state говорит «error», показывайте сообщение. Если state говорит «items = 3», отрисуйте три строки. Ваша задача — держать UI читающим state, а не уходящим в скрытые переменные.

Быстрое разделение понятий:

• Компонент: кусок UI (SearchBox, ProfileCard, CheckoutForm)
• Props: что нужно показать (name, price, disabled)
• State: что запоминается (isOpen, query, selectedId)

Пример: модалка. Родитель может передать title и onClose как props. Модалка может владеть isAnimating в state.

Даже если вы генерируете UI через чат (например, на Koder.ai), такое разделение всё равно — самый быстрый способ не сойти с ума: сначала решите, что будет props, а что state, а затем дайте интерфейсу следовать этому плану.

Рендер и ререндер: что на самом деле меняется

Полезная мысль о React (в духе Dan Abramov): рендер — это вычисление, а не покраска. React запускает функции ваших компонентов, чтобы понять, как UI должен выглядеть для текущих props и state. Результат — описание UI, а не пиксели.

Ререндер просто означает, что React повторяет это вычисление. Это не значит «весь сайт перерисовался». React сравнивает новый результат со старым и применяет минимальный набор изменений к реальному DOM. Многие компоненты могут ререндериться, тогда как реально обновится только пара узлов DOM.

Большинство ререндеров происходят по простым причинам: изменился state компонента, изменились его props или родитель перерендерился и React попросил ребёнка снова отрендериться. Последний пункт иногда удивляет, но обычно это нормально. Если вы будете считать рендер «дёшевым и скучным», приложение станет легче для понимания.

Правило большого пальца: делайте render чистым. При одинаковых входных данных (props + state) компонент должен возвращать одинаковое описание UI. Убирайте сюрпризы из render.

Конкретный пример: если вы генерируете ID через Math.random() внутри render, при ререндере он изменится, и, например, чекбокс потеряет фокус или элемент списка переинициализируется. Создавайте ID один раз (в state, через memo или вне компонента), и render станет стабильным.

Если запомнить одно предложение: ререндер — это «пересчитать, каким должен быть UI», а не «перестроить всё заново».

Обновления state: делайте изменения маленькими и предсказуемыми

Ещё одна полезная модель: обновления state — это запросы, а не немедленные присваивания. Когда вы вызываете сеттер вроде setCount(count + 1), вы просите React запланировать рендер с новым значением. Если вы прочитаете state сразу после этого, вы можете увидеть старое значение, потому что React ещё не отрендерил.

Именно поэтому важны «малые и предсказуемые» обновления. Предпочитайте описывать изменение вместо того, чтобы хвататься за то, что вы думаете текущим значением. Когда следующее значение зависит от предыдущего, используйте форму апдейтера: setCount(c => c + 1). Это соответствует тому, как React работает: несколько обновлений могут помещаться в очередь и затем применяться по порядку.

Иммутабельность — другая половина картины. Не изменяйте объекты и массивы на месте. Создавайте новый объект с изменением. Тогда React может увидеть «значение новое», а вам легче отследить, что поменялось.

Пример: переключение todo. Безопасный подход — создать новый массив и новый объект todo для изменённого элемента. Рискованный — делать todo.done = !todo.done внутри существующего массива.

Также держите state минимальным. Частая ловушка — хранить значения, которые можно вычислить. Если у вас есть items и filter, не храните filteredItems в state. Вычисляйте это во время render. Чем меньше переменных state, тем меньше способов для рассинхронизации.

Простой тест для определения, что должно быть в state:

• Храните, если это может меняться со временем и UI должен на это реагировать.
• Не храните, если это можно вывести из других state или props.
• Не храните дублирующих истин в двух местах.

Если вы строите UI через чат (включая Koder.ai), просите изменения маленькими патчами: «Добавь один булев флаг» или «Обнови этот список иммутабельно». Малые и явные изменения держат генератор и ваш React‑код в согласии.

Эффекты нужны для синхронизации, а не для базовой логики UI

Рендер описывает UI. Эффекты синхронизируются с внешним миром. «Внешний» — это то, чем React не управляет: сетевые запросы, таймеры, браузерные API и иногда императивная работа с DOM.

Если что‑то можно вычислить из props и state, обычно это не должно жить в эффекте. Помещая это в эффект, вы добавляете второй шаг (render → run effect → set state → render). Эта лишняя ступень — место, где появляются мерцания, петли и баги «почему это устарело?».

Типичная путаница: у вас есть firstName и lastName, и вы храните fullName в state с помощью эффекта. Но fullName не является сайд‑эффектом. Его лучше вычислить в render, и тогда он всегда будет совпадать.

Как правило: вычисляйте UI‑значения в render (или с useMemo, если дорого), а эффекты используйте для «что‑то сделать» — fetch, таймеры, подписки, сохранение и т.п., а не для «разобраться, что показать».

Массив зависимостей — это список триггеров

Относитесь к массиву зависимостей как к: «Когда эти значения меняются — нужно заново синхронизироваться с внешним миром». Это не трюк для производительности и не место для подавления предупреждений.

Пример: если вы запрашиваете данные при изменении userId, userId должен быть в массиве зависимостей, потому что он должен триггерить синхронизацию. Если эффект использует token — включите и его, иначе можно будет выполнить запрос со старым токеном.

Хорошая проверка интуиции: если удаление эффекта только делает UI неправильным, то, вероятно, это не настоящий эффект. Если удаление прекратит таймер, отменит подписку или пропустит fetch — то, вероятно, это эффект.

Поток данных: один источник истины лучше рассеянного состояния

Одна из самых полезных ментальных моделей проста: данные текут вниз по дереву, а действия пользователя — вверх.

Родитель передаёт значения детям. Дети не должны тайно «владеть» той же самой информацией в двух местах. Они должны запрашивать изменения, вызывая функцию, а родитель решает, каким будет новое значение.

Когда две части UI должны соглашаться, выберите одно место для хранения значения и передайте его вниз. Это и есть «lifting state». Может показаться лишней сантехникой, но это предотвращает гораздо худшую проблему: два состояния, которые расходятся, и необходимость править костылями, чтобы их держать синхронными.

Пример: поисковая строка и список результатов. Если инпут хранит свой query, а список хранит свой query, рано или поздно вы увидите «инпут показывает X, а список использует Y». Решение — держать query в родителе, передавать его обоим и давать инпуту onChangeQuery(newValue).

Поднимать state не всегда нужно. Если значение важно только внутри одного компонента — держите его там. Держать state близко к месту использования обычно делает код понятнее.

Практическая граница:

• Локальный state: детали UI (выпадашка открыта, какая вкладка подсвечена)
• Общий state: данные, о которых должны соглашаться несколько компонентов (фильтры, выбранный элемент, статус авторизации)

Если вы сомневаетесь, поднимайте state, когда видите признаки: два компонента показывают одно и то же по‑разному; действие в одном месте должно обновить что‑то далеко; вы копируете props в state «на всякий случай»; или вы добавляете эффекты только чтобы держать два значения синхронизированными.

Эта модель также помогает при сборке через чат‑инструменты вроде Koder.ai: попросите один владелец для каждого фрагмента общего состояния и генерируйте обработчики, которые поднимают изменения вверх.

Шаг за шагом: проектируйте фичу, сначала нарисовав state

Выберите фичу, достаточно маленькую, чтобы её удержать в голове. Хороший пример — список с поиском, где по клику на элемент открывается модалка с деталями.

Начните со схемы частей UI и событий, которые могут произойти. Пока не думайте о коде. Подумайте, что пользователь может делать и что он видит: есть поисковый инпут, список, подсветка выбранной строки и модалка. События: ввод в поиск, клик на элемент, открытие модалки, закрытие модалки.

Теперь «нарисуйте state». Запишите несколько значений, которые нужно хранить, и решите, кто ими владеет. Простое правило: ближайший общий родитель тех мест, которые нуждаются в значении, должен владеть им.

Для этой фичи состояние может быть крошечным: query (строка), selectedId (id или null), isModalOpen (булево). Список читает query и рендерит элементы. Модалка читает selectedId, чтобы показать детали. Если и список, и модалка пользуются selectedId, храните его в родителе, а не в обоих.

Далее отделите производные данные от хранимых. Отфильтрованный список — производное: filteredItems = items.filter(...). Не храните его в state, потому что его всегда можно пересчитать из items и query. Хранение производного — источник дрейфа значений.

Только потом спросите: нужен ли эффект? Если элементы уже в памяти — нет. Если ввод должен выполнять fetch — да. Если закрытие модалки должно что‑то сохранять — да. Эффекты — для синхронизации (fetch, save, subscribe), а не для базовой логики UI.

Наконец, протестируйте поток на парах кейсов:

• Печатать быстро, потом очистить ввод: возвращается ли список к норме?
• Кликнуть элемент, затем список меняется из‑за поиска: валиден ли selectedId?
• Закрыть модалку: сохраняется ли выбор или сбрасывается?
• Данные обновились с сервера: что происходит, если выбранный элемент исчез?

Если вы можете ответить на эти вопросы на бумаге, писать React‑код обычно просто.

Частые ошибки, разрушающие ментальную модель

Большая часть путаницы в React не в синтаксисе. Она возникает, когда код перестаёт соответствовать простой истории в вашей голове.

Шаблоны ошибок (и симптом, который вы заметите)

Хранение производного состояния. Вы сохраняете fullName в state, хотя это просто firstName + lastName. Это работает до тех пор, пока одно поле не изменится, а другое — нет, и UI покажет устаревшее значение.

Петли в эффектах. Эффект делает fetch, ставит state, а список зависимостей заставляет его снова выполняться. Симптом: повторяющиеся запросы, дергающийся UI или состояние, которое не стабилизируется.

Устаревшие замыкания. Обработчик клика читает старое значение (например, устаревший счётчик или фильтр). Симптом: «я кликнул, но он использовал вчерашнее значение».

Глобальное состояние везде. Кладёте все детали UI в глобальный стор — потом сложно понять, кто за что отвечает. Симптом: вы меняете одно, и реагируют три экрана непредсказуемо.

Мутация вложенных объектов. Обновляете объект или массив на месте и удивляетесь, почему UI не обновился. Симптом: «данные изменились, но ничего не перерендерилось».

Конкретный пример: панель «поиск и сортировка» для списка. Если вы храните filteredItems в state, оно может уйти от items, когда придут новые данные. Вместо этого храните входы (поиск, сорт) и вычисляйте список в render.

С эффектами держите их для синхронизации с внешним миром (fetch, подписки, таймеры). Если эффект занимается базовой логикой UI — часто ему не место в эффекте.

При генерации или редактировании кода через чат эти ошибки проявляются быстрее, потому что изменения приходят большими кусками. Хорошая привычка — формулировать запросы через владельцев: «Какой источник истины для этого значения?» и «Можем ли мы вычислить это вместо хранения?».

Быстрый чек‑лист, когда state начинает путаться

Когда UI ведёт себя непредсказуемо, редко виноват сам React. Чаще всего — слишком много state, в неправильных местах или выполняющий чужую работу.

Прежде чем добавлять ещё один useState, остановитесь и спросите:

• Какой минимальный набор значений полностью описывает то, что пользователь видит прямо сейчас?
• Где должно жить каждое значение, чтобы те, кому оно нужно, могли его читать, а те, кому не нужно — оставались спокойны?
• Это значение действительно новая информация или его можно вычислить из props, URL‑параметров или других state?
• Вы используете эффект чтобы вычислить UI или только для синхронизации с внешним миром (сеть, таймеры, APIs)?
• При изменении одного значения, какие компоненты должны перерендериться, потому что они его читают, а какие — нет?

Небольшой пример: поисковая строка, выпадающий фильтр, список. Если вы храните и query, и filteredItems в state, у вас теперь два источника истины. Вместо этого держите query и filter в state, а filteredItems выводите в render из полного списка.

Это важно и при быстрой работе через чат‑инструменты. Скорость — хорошо, но продолжайте спрашивать: «Мы добавили state или по ошибке добавили вычисляемое значение?» Если это вычисляемое — удалите state и вычисляйте его.

Пример: быстро итератировать интерфейс, не потеряв предсказуемости

Небольшая команда делает админку: таблица заказов, пара фильтров и диалог для редактирования. Первый запрос часто звучит расплывчато: «Добавьте фильтры и всплывающее окно редактирования». Это кажется просто, но часто превращается в рассыпавшееся состояние.

Сделайте запрос конкретным, переводя его в состояние и события. Вместо «фильтры» назовите состояние: query, status, dateRange. Вместо «всплывашка редактирования» назовите событие: «пользователь нажимает Edit у строки». Затем решите, кто владеет чем (страница, таблица или диалог) и что можно вывести.

Примеры подсказок, которые сохраняют модель (они же хорошо работают в чат‑генераторах типа Koder.ai):

• «Создайте OrdersPage, который владеет filters и selectedOrderId. OrdersTable контролируется filters и вызывает onEdit(orderId).»
• «Вычисляйте visibleOrders из orders и filters. Не храните visibleOrders в state.»
• «Добавьте EditOrderDialog, который получает order и open. При сохранении вызывайте onSave(updatedOrder) и закрывайте диалог.»
• «Если данные подгружаются, храните их в одном месте. Эффект используйте только для синхронизации filters в URL, а не для вычисления строк.»

После генерации или обновления UI быстро проверьте изменения: каждое состояние имеет одного владельца, производные значения не хранятся, эффекты нужны только для синхронизации с внешним миром (URL, сеть, storage), и события текут вниз как props, вверх как колбэки.

Когда состояние предсказуемо, итерация становится безопасной. Вы можете изменить макет таблицы, добавить фильтр или поправить поля диалога, не догадываясь, какое скрытое состояние внезапно сломается.

Следующие шаги: быстрее собирать через чат, но сохранять модель React

Скорость полезна, если приложение остаётся понятным. Самая простая защита — применять эти ментальные модели как чек‑лист перед написанием или генерацией UI.

Начинайте каждую фичу одинаково: выпишите нужный state, события, которые его меняют, и кто его владеет. Если вы не можете сказать «Этот компонент владеет этим состоянием, а эти события его меняют», скорее всего вы получите рассеянное состояние и неожиданные ререндеры.

Если вы строите через чат, начните с режима планирования. Опишите компоненты, форму состояния и переходы простым языком перед запросом кода. Например: «Панель фильтров обновляет состояние query; список результатов выводится из query; выбор элемента ставит selectedId; закрытие очищает его.» Как только это читается понятно, генерация UI становится механической.

Если вы пользуетесь Koder.ai (koder.ai) для генерации React‑кода, стоит сделать быструю проверку здравого смысла: один явный владелец для каждого значения state, UI выводится из state, эффекты только для синхронизации, и нет дублирующих источников истины.

Делайте итерации малыми шагами. Если хотите изменить форму состояния (например, несколько флагов → одно поле status), сначала снимите снапшот, попробуйте, и откатитесь, если модель стала хуже. При более глубоком ревью или перед передачей кода, экспорт исходников поможет ответить на реальный вопрос: сохраняет ли форма состояния историю UI?