Почему управление состоянием — одна из самых сложных задач фронтенда

Что на самом деле означает «состояние» в фронтенд-приложении

Определение простыми словами

В фронтенд-приложении состояние — это просто данные, от которых зависит интерфейс и которые могут меняться со временем.

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

Распространённые примеры, которые вы видите каждый день

Состояние проявляется в небольших и больших взаимодействиях, например:

• Поля формы: что пользователь ввёл, установлен ли флажок, какие ошибки показывать
• Навигационные выборы: выбранная вкладка, текущий шаг в мастере, раскрытые/свернутые секции
• Данные корзины/покупки: товары, количества, применённые купоны, рассчитанные итоги
• Сессия пользователя: данные авторизованного пользователя, права доступа, feature-флаги, настройка "запомнить меня"

Некоторые из этих состояний «временные» (например, выбранная вкладка), другие кажутся «важными» (например, корзина). Они все — состояние, потому что влияют на то, что UI рендерит прямо сейчас.

Почему состояние — это не просто «переменные в компоненте»

Обычная переменная важна только там, где она живёт. С состоянием всё по-другому, потому что у него есть правила:

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

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

Почему состояние кажется простым сначала (а потом вдруг — нет)

В начале фронтенд-проекта состояние кажется почти скучным — в хорошем смысле. У вас один компонент, одно поле и одно очевидное обновление. Пользователь вводит значение, вы сохраняете это значение, и UI перерисовывается. Всё видно, мгновенно и локально.

Простой случай: один компонент, одно обновление

Представьте одно текстовое поле с превью того, что вы ввели:

• Состояние живёт в том же компоненте, который рендерит поле.
• Обновление происходит в прямом ответе на действие пользователя.
• Нет споров о том, «кто владеет» данными.

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

Почему локальное состояние кажется простым

Локальное состояние работает, потому что ментальная модель совпадает со структурой кода:

• Область видимости мала (один компонент, возможно пара детей).
• С точки зрения пользователя обновления синхронны.
• Поток данных очевиден: ввод → обновление → рендер.

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

Что меняется по мере роста приложения

Как только приложение перестаёт быть «страницей с виджетом» и становится «продуктом», состояние перестаёт жить в одном месте.

Теперь одна и та же часть данных может понадобиться в:

• нескольких экранах (навигация)
• отдалённых компонентах (общий UI)
• перезагрузках и рестартах (постоянство)
• нескольких пользователях/устройствах (синхронизация с сервером)

Имя профиля может отображаться в шапке, редактироваться на странице настроек, кешироваться для более быстрой загрузки и использоваться для персонализации приветствия. Внезапно вопрос не «как хранить это значение?», а «где это значение должно жить, чтобы оставаться правильным везде?»

Сложность растёт нелинейно

Сложность состояния не нарастает постепенно с добавлением фич — она делает скачки.

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

Слишком много источников правды

Состояние становится болезненным, когда один и тот же «факт» хранится в нескольких местах. Каждая копия может рассинхронизироваться, и теперь UI начинает спорить сам с собой.

Обычные подозреваемые

Большинство приложений в итоге имеют несколько мест, которые могут хранить «правду»:

• Данные на сервере (API/БД): каноническая запись
• Клиентский кеш (например, кеш библиотеки для запросов): локальная копия, которую нужно обновлять
• Локальное UI-состояние (состояние компонента): то, что пользователь делает прямо сейчас
• URL (путь, query-параметры, hash): состояние, которое можно закладировать, поделиться и восстановить

Все эти места — валидные владельцы для какой-то части состояния. Проблема начинается, когда они все пытаются владеть одним и тем же состоянием.

Как возникает дублирование

Обычная схема: загрузили данные с сервера, затем скопировали их в локальное состояние «чтобы редактировать». Например: вы загрузили профиль пользователя и сделали formState = userFromApi. Позже сервер перезагрузился (или в другой вкладке запись обновилась), и у вас теперь две версии: кеш говорит одно, ваша форма — другое.

Дублирование также пробирается через «полезные» трансформации: хранение и items, и itemsCount, или selectedId и selectedItem одновременно.

Симптомы, которые вы узнаете

Когда есть несколько источников правды, баги обычно звучат как:

• «Это работает только на этом экране.»
• UI неконсистентен после навигации или обновления страницы.
• Данные выглядят правильно в одном компоненте, но устаревшими в другом.
• Сохранение прошло успешно, но список не обновился (или обновился дважды).

Правило большого пальца

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

Асинхронная работа и сайд-эффекты усложняют состояние

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

Что считается сайд-эффектом?

Сайд-эффекты — это любые действия, которые выходят за рамки чистой модели компонента «рендерить по данным»:

• Сетевые вызовы (загрузка, сохранение, повторы)
• Таймеры и дебаунсинг (setTimeout, intervals)
• Подписки (web socket, слушатели событий)
• Хранение в браузере (localStorage/sessionStorage)

Каждый из них может сработать позже, завершиться с ошибкой или выполниться несколько раз.

Почему асинхронное состояние сложнее синхронного

Асинхронные обновления вводят время как переменную. Вы уже не размышляете только «что произошло», а «что ещё может происходить». Два запроса могут перекрываться. Медленный ответ может прийти позже более нового. Компонент может размонтироваться, пока асинхронный колбэк всё ещё пытается обновить состояние.

Поэтому баги часто выглядят так:

• Флаги загрузки застревают навсегда (путь ошибки не очистил их, или запрос был отменён)
• UI мигом показывает старые данные (устаревшее кеш-значение показано как «финальное»)
• Устаревшие ответы перезаписывают новые (запрос A завершился после запроса B)

Простая стратегия: моделировать запрос явно

Вместо того чтобы разбросать булевы флаги вроде isLoading по всему UI, рассматривайте асинхронную работу как небольшой конечный автомат:

• idle (ничего не начато)
• loading (в процессе)
• success (данные доступны)
• error (ошибка зафиксирована)

Отслеживайте данные и статус вместе, и храните идентификатор (например, id запроса или ключ запроса), чтобы можно было игнорировать поздние ответы. Тогда вопрос «что UI должен показать прямо сейчас?» превращается в однозначное решение, а не в догадку.

Состояние UI vs серверное состояние (они похожи, но разные)

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

UI-состояние: что делает интерфейс

UI-состояние временно и управляется взаимодействиями. Оно существует для того, чтобы отобразить экран так, как пользователь ожидает в этот момент.

Примеры: открытые/закрытые модальные окна, активные фильтры, черновик ввода в поиске, hover/focus, выбранная вкладка и UI-пагинация (текущая страница, размер страницы, позиция прокрутки).

Обычно такое состояние локально для страницы или дерева компонентов. Нормально, если оно сбрасывается при навигации.

Серверное состояние: то, что вы получили (и что может измениться где-то ещё)

Серверное состояние — это данные из API: профили пользователей, списки продуктов, права доступа, уведомления, сохранённые настройки. Это «удалённая правда», которая может измениться без действий вашего UI (кто-то другой её редактирует, сервер пересчитывает значения, фоновые задания обновляют данные).

Поскольку это удалённые данные, им нужны метаданные: состояние загрузки/ошибки, метки времени кеша, повторы и инвалидация.

Почему их смешение вызывает путаницу

Если вы храните черновики UI внутри серверных данных, рефетч может стереть локальные правки. Если вы храните ответы сервера в UI-состоянии без правил кеширования, вы будете бороться с устаревшими данными, дублирующимися запросами и несогласованными экранами.

Типичная ошибка: пользователь редактирует форму, а в фоне завершился рефетч и пришёл ответ, который перезаписал черновик.

Практическое руководство

Управляйте серверным состоянием с паттернами кеширования (fetch, cache, invalidate, refetch on focus) и рассматривайте его как разделяемое и асинхронное.

Управляйте UI-состоянием с помощью UI-инструментов (локальное состояние компонента, context для действительно общих UI-вещей) и держите черновики отдельно, пока вы явно не нажмёте «сохранить» на сервер.

Производное состояние и правило «не храните то, что можно вычислить»

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

Соблазнительно хранить такие значения, потому что это удобно («я просто сохраню total тоже»). Но как только входы меняются в нескольких местах, вы рискуете рассинхроном: сохранённый total больше не соответствует items, фильтрованный список не отражает текущий запрос, или кнопка отправки остаётся отключённой после исправления ошибки. Такие баги раздражают, потому что по отдельности каждая переменная валидна — просто несогласована с остальными.

Отдавайте предпочтение селекторам/вычислениям

Более безопасный паттерн: храните минимальные исходники правды и вычисляйте всё остальное при чтении. В React это может быть простая функция или мемоизированный расчёт.

const items = useCartItems();
const total = items.reduce((sum, item) => sum + item.price * item.qty, 0);

const filtered = products.filter(p => p.name.includes(query));

В больших приложениях «селекторы» (или вычисляемые геттеры) формализуют эту идею: одно место описывает, как выводить total, filteredProducts, visibleTodos, и все компоненты используют одну и ту же логику.

Когда кеширование производных значений допустимо

Вычислять при каждом рендере обычно нормально. Кешируйте только когда у вас действительно измеренная проблема: дорогие трансформации, огромные списки или производное значение, которое разделяется между многими компонентами. Используйте мемоизацию (useMemo, мемоизация селекторов), чтобы ключи кеша были настоящими входами — иначе вы снова получите дрейф, просто под видом оптимизации.

Глобальное vs локальное: выбор правильного владельца

Состояние становится болезненным, когда неясно, кто владеет им.

Что означает «владение»

Владелец фрагмента состояния — это место в приложении, которое имеет право обновлять его. Другие части UI могут читать его (через props, context, селекторы и т.д.), но не должны менять напрямую.

Чёткое владение отвечает на два вопроса:

• Кто может обновлять это значение? (владелец)
• Кто может читать это значение? (потребители)

Когда границы размыты, вы получаете конфликтующие обновления, моменты «почему это изменилось?» и компоненты, которые трудно переиспользовать.

Глобальное состояние: удобно, но втягивает связность

Поместить состояние в глобальный стор (или в context верхнего уровня) кажется аккуратно: всё может получить доступ, и вы избегаете прокидывания props. Обратная сторона — неожиданная связность: вдруг несвязанные экраны зависят от одних и тех же значений, и небольшие изменения распространяются по всему приложению.

Глобальное состояние подходит для действительных кросс-приложных вещей: текущая сессия пользователя, глобальные feature-флаги или общая очередь нотификаций.

Поднимайте состояние — только так далеко, как нужно

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

Если состояние нужно только одному компоненту, держите его там. Если нужно нескольким компонентам, поднимайте к наименьшему общему владельцу. Если оно нужно многим далеко расположенным частям — тогда рассматривайте глобальное хранение.

Простая эвристика

Держите состояние близко к месту использования, если только совместное использование действительно не требуется.

Это делает компоненты проще для понимания, уменьшает случайные зависимости и облегчает будущие рефакторы.

Конкурентность, гонки и внепорядковые обновления

Фронтенд-приложения кажутся «однопоточными», но ввод пользователя, таймеры, анимации и сетевые запросы работают независимо. Это значит, что несколько обновлений могут быть в полёте одновременно — и они не обязательно завершаются в том порядке, в котором были запущены.

Когда обновления сталкиваются

Распространённый конфликт: две части UI обновляют одно и то же состояние.

• Поисковая строка обновляет query при каждом нажатии клавиши.
• Выпадающий фильтр обновляет query (или тот же список результатов) при выборе.

По отдельности каждое обновление корректно. Вместе они могут перезаписать друг друга в зависимости от тайминга. Ещё хуже — вы можете показывать результаты для предыдущего запроса, пока UI отображает новые фильтры.

Условия гонки: быстрые пользователи, медленные сети

Условия гонки возникают, когда вы отправляете запрос A, потом быстро отправляете запрос B — но запрос A возвращается последним.

Пример: пользователь набирает «c», «ca», «cat». Если запрос для «c» медленный, а запрос для «cat» быстрый, UI может кратко показать результаты «cat», а затем быть перезаписанным устаревшими результатами «c», когда тот ответ придёт позже.

Ошибка тонкая, потому что «всё работало» — просто в неправильном порядке.

Приёмы, уменьшающие внепорядковые баги

Обычно вы хотите одну из стратегий:

1. Отменять предыдущий запрос, когда появляется новый (например, используя AbortController).
2. Игнорировать устаревшие ответы, проверяя, соответствует ли ответ последним входным данным.
3. Использовать ID запросов / порядковые номера и принимать только самые новые.

Простой подход с request ID:

let latestRequestId = 0;

async function fetchResults(query) {
  const requestId = ++latestRequestId;
  const res = await fetch(`/api/search?q=${encodeURIComponent(query)}`);
  const data = await res.json();

  if (requestId !== latestRequestId) return; // устаревший ответ
  setResults(data);
}

Оптимистические обновления (и как они ломаются)

Оптимистические обновления делают интерфейс мгновенным: вы меняете экран до подтверждения сервера. Но конкуренция может разрушить предположения:

• Пользователь быстро нажимает «лайк» дважды (лайк → анлайк), но запросы завершаются в неправильном порядке.
• Вы оптимистично уменьшили количество на складе, затем позднее пришла ошибка и нужно откатиться — но пользователь уже ушёл или сделал другие изменения.

Чтобы безопасно использовать оптимизм, обычно нужен чёткий механизм согласования: отслеживайте ожидающее действие, применяйте ответы сервера в порядке и, если нужно, откатывайтесь к известной контрольной точке (не к «тому, как сейчас выглядит UI").

Производительность: когда изменения состояния слишком дороги

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

Почему маленькое изменение может казаться большим

Один переключатель может случайно запустить много лишней работы:

• Большие секции UI перерисовываются, хотя изменился только маленький фрагмент.
• Списки заново отрисовываются и измеряются, что вызывает рывки при прокрутке.
• Объекты и массивы пересоздаются при каждом обновлении («глубокая смена»), поэтому приложение не может легко определить, что реально изменилось.

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

Частые ловушки производительности

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

Ещё одна ловушка — хранение вычисленных значений в состоянии и обновление их вручную. Это часто создаёт лишние обновления (и лишнюю работу UI), чтобы всё держать в синхронизации.

Тактики для быстрой UI

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

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

Мемоизируйте производные значения. Если значение можно вычислить из другого состояния (например, отфильтрованные результаты), кешируйте расчёт, чтобы он выполнялся только когда входы действительно изменились.

Цель: меньше тормозов, меньше сюрпризов

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

Отладка и тестирование состояния без догадок

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

Делайте изменения отслеживаемыми (не мистическими)

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

• Изменения происходят через небольшой набор хорошо названных действий (не случайные мутации)
• Каждое действие имеет явную нагрузку (setShippingMethod('express'), а не updateStuff)
• Вы можете логировать действия и переходы состояния последовательно

Ясное логирование действий превращает отладку из «пялиться на экран» в «следовать по чеку». Даже простые console.log (имя действия + ключевые поля) лучше, чем попытки восстановить последовательность по симптомам.

Тестируйте логику там, где она стабильна

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

• Юнит-тестируйте редьюсеры / обновители состояния: дано предыдущее состояние + действие — проверяйте следующее состояние
• Юнит-тестируйте селекторы / вычисления: дано состояние — проверяйте вычисленный результат
• Интеграционные тесты ключевых пользовательских сценариев: логин → загрузка данных → редактирование → сохранение → подтверждение

Такой микс ловит и «математические» баги, и реальные проблемы проводки.

Добавьте лёгкую телеметрию для асинхронных багов

Асинхронные проблемы прячутся в разрывах. Добавьте минимальную метаинформацию, которая делает временные линии видимыми:

• метки времени на важных обновлениях
• ID запросов (прикрепляйте ID к действиям и ответам)

Тогда, когда поздний ответ перезаписывает более новый, вы можете сразу это доказать — и исправить с уверенностью.

Выбор подхода к управлению состоянием (без войн инструментов)

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

Критерии выбора, которые действительно важны

Практический способ принять решение — посмотреть на несколько ограничений:

• Размер и жизненный цикл приложения: маленький внутренний инструмент можно держать простым; долго живущий продукт выигрывает от строгих соглашений.
• Привычки команды: выберите то, что команда сможет использовать последовательно (и ревьюить уверенно).
• Асинхронные потребности: тяжёлые загрузки, кеширование, пагинация и мутации меняют уравнение.
• Сложность состояния: кросс-страничные рабочие процессы, отмена/повтор и многошаговые формы часто требуют больше структуры.

Высокоуровневое сравнение (без идеологии)

• Context + hooks: отлично для dependency injection и редко обновляемых общих значений (тема, auth-info). Может подойти для состояния, но частые обновления будут шуметь без дополнительных паттернов.
• Redux-стиль сторы: сильные соглашения, предсказуемые обновления и хорошая экосистема инструментов. Подходит, когда нужен ясный аудит или сложная координация между фичами.
• Atom-сторы (тонкое состояние): эргономичны для разделяемого состояния без большого количества редьюсеров. Часто проще масштабироваться постепенно.
• Query-кеши (инструменты для серверного состояния): специализированы для загрузки, кеширования, дедупа, фонового рефетча и мутаций. Они снимают большую часть «асинхронного клеевого кода».

Избегайте мышления «инструмент — первая вещь»

Если вы начинаете с «мы везде используем X», вы будете хранить не те вещи в не тех местах. Начните с владения: кто обновляет значение, кто читает и что должно происходить при изменении.

Комбинирование инструментов часто — лучшее решение

Многие приложения успешно используют библиотеку для серверного состояния для API-данных и небольшое решение для UI-состояния для клиентских дел (модалки, фильтры, черновики форм). Цель — ясность: каждый тип состояния живёт там, где его проще понять.

Где помогает Koder.ai

Если вы итеративно пробуете границы состояния и асинхронные потоки, Koder.ai может ускорить цикл «попробовать, наблюдать, доработать». Поскольку он генерирует React-фронтенды (и Go + PostgreSQL бэкенды) через агентно-ориентированный workflow, вы можете быстро прототипировать альтернативные модели владения (локальное vs глобальное, кеш сервера vs черновики UI) и оставить ту версию, которая остаётся предсказуемой.

Две практические фичи, полезные при экспериментах со состоянием: Planning Mode (чтобы заранее спланировать модель состояния) и snapshots + rollback (чтобы безопасно тестировать рефакторы вроде «убрать производное состояние» или «ввести request IDs» без потери рабочей версии).

Практический чеклист, чтобы состояние было менее болезненным

Состояние становится проще, когда вы рассматриваете его как дизайнерскую задачу: решаете, кто владеет им, что оно представляет и как оно меняется. Используйте этот чеклист, когда компонент начинает казаться «загадочным».

1) Уточните владение и единый источник правды

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

• Один владелец для одного фрагмента состояния.
• Передавайте данные вниз; отправляйте изменения наверх через колбэки/события.
• Если два места могут обновлять одно и то же значение — у вас нет источника правды, а есть конфликт, ожидающий своего часа.

2) Избегайте дублирования и моделируйте производные значения

Если можно что-то вычислить из других данных — не храните это отдельно.

• Храните минимальные входные данные (например, items, filterText).
• Вычисляйте выводы (например, visibleItems) в рендере или через мемоизацию.

3) Делайте асинхронные состояния явными (не подразумеваемыми)

Асинхронная работа понятнее, когда вы моделируете её явно:

• Предпочитайте небольшую форму состояния запроса: status: 'idle' | 'loading' | 'success' | 'error', плюс data и error.
• Рассматривайте «загрузку» и «ошибку» как полноценные состояния UI, а не как разбросанные булевы флаги.

4) Следите за распространёнными антипаттернами

• Копирование props в state «на всякий случай» (создаёт дрейф).
• Глобализация всего подряд (связывает несвязанные экраны).
• Булево-лук (isLoading, isFetching, isSaving, hasLoaded, …) вместо единого статуса.

5) Рефакторьте маленькими безопасными шагами

• Разделяйте смешанное состояние: отделяйте UI-задачи (открыто/закрыто, текст ввода) от серверных данных.
• Удаляйте сохранённые производные значения и вычисляйте их от реального источника.
• Централизуйте сайд-эффекты (загрузку, подписки) в одном месте на фичу.

Практические цели

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