Реактивный подход — это способ описать интерфейс так, чтобы он обновлялся сам при изменении данных, а разработчик не расставлял вручную десятки команд «обнови вот это поле». Для сложных экранов разница принципиальная: либо поддерживаемый код, либо бесконечная охота за случаями, когда одно значение обновилось, а связанное с ним — нет.
В чём проблема ручного обновления
Возьмём типовой сценарий из интернет-магазина. Покупатель меняет количество товара в корзине. После этого нужно пересчитать сумму строки, общую сумму заказа, размер скидки, стоимость доставки, наличие бесплатной доставки при превышении порога, доступность кнопки оформления и остаток на складе. Семь величин, связанных между собой.
Когда каждое обновление прописано отдельной командой, добавление восьмой величины требует пройти по всем местам, где меняется количество, и дописать её туда. Рано или поздно один из путей забудут — например, изменение количества через удаление позиции или через применение промокода. Так появляется дефект, который трудно поймать: «иногда сумма неправильная». Он не воспроизводится по шагам, потому что зависит от порядка действий.
Мы разбирали такие ошибки на чужих проектах не раз. Обычно причина одна и та же: величина считается в трёх местах, и в одном из них формулу забыли обновить после изменения правил скидок.
Как выглядит реактивный вариант
Данные объявляются как источник, а всё производное — как функция от источника. Сумма строки описана как произведение количества на цену, сумма заказа — как сумма строк, доступность кнопки — как условие «сумма больше нуля и адрес заполнен». Изменилось количество — пересчиталось всё, что от него зависит, потому что связь описана один раз в момент объявления, а не в каждом обработчике.
Ошибок «забыли обновить» в такой схеме не остаётся по построению: чтобы значение не пересчиталось, надо специально разорвать связь. Добавление новой величины сводится к одной строке с формулой, а не к обходу всех мест, где меняются исходные данные.
Отдельный выигрыш — читаемость. Формула «итог равен сумме строк минус скидка плюс доставка» записана в коде примерно так же, как её проговаривает заказчик. Проверять такое описание на соответствие требованиям заметно проще, чем цепочку присваиваний.
Где подход оправдан
| Экран | Нужен ли реактивный подход | Почему |
|---|---|---|
| Корзина, калькулятор, конфигуратор | Да | Много взаимозависимых величин, правила меняются |
| Фильтры каталога | Да | Состояние меняется постоянно, влияет на список и на адрес страницы |
| Личный кабинет с таблицами | Да | Сортировки, выделение строк, массовые действия |
| Многошаговая форма с зависимыми полями | Скорее да | Видимость и обязательность полей зависят от предыдущих ответов |
| Форма из трёх полей | Нет | Достаточно обычного обработчика отправки |
| Страница услуги или статья | Нет | Содержимое статично, лишний вес и сложность |
Чем за это платят
- Порог входа. Нужно понимать, как устроены зависимости и когда именно происходит пересчёт. Разработчик, привыкший к прямым обработчикам, сначала пишет реактивный код как обычный и не получает выигрыша.
- Отладка. Причина обновления не всегда очевидна: значение изменилось, потому что изменилось другое значение, о котором в этом файле ничего не сказано.
- Каскады. Одно изменение тянет цепочку пересчётов, и если в цепочке есть тяжёлая операция вроде запроса на сервер, она выполняется чаще, чем нужно.
- Вес. На страницу добавляется библиотека. Для кабинета это несущественно, для посадочной страницы — заметно.
- Утечки подписок. Если связь создана, а при уходе с экрана не разорвана, обработчики накапливаются. На длинных сессиях это выливается в подтормаживание.
Как избежать типичных проблем
- Разделяем источники и производные значения явно. Если величину можно вычислить, её не хранят отдельно: две копии одного числа рано или поздно разойдутся.
- Держим состояние как можно ближе к тому месту, где оно используется. Глобальное хранилище на весь проект превращается в свалку через полгода.
- Выносим побочные действия — запросы к серверу, запись в хранилище браузера — в отдельный слой, а не в формулы пересчёта.
- Ограничиваем частоту тяжёлых операций: поиск по мере ввода не должен отправлять запрос на каждое нажатие клавиши.
- Проверяем на реальных объёмах. Таблица на пятьдесят строк ведёт себя иначе, чем на пять тысяч.
Как это влияет на скорость страницы
Реактивная библиотека добавляет к странице код, который нужно скачать, разобрать и выполнить до того, как интерфейс начнёт отвечать на нажатия. На настольном компьютере с быстрой сетью разница почти не заметна, на телефоне среднего класса — заметна вполне: время до готовности к взаимодействию растёт, а посетитель в этот момент уже видит кнопку и пытается на неё нажать.
Отсюда практическое следствие: подключать библиотеку стоит там, где она действительно работает. Мы стараемся не тянуть весь фреймворк ради одного счётчика в шапке. Если сложный экран один, его код грузится отдельно и только на этом экране, а остальные страницы остаются лёгкими. На проектах, где реактивность применили ко всему подряд, мы обычно и находим главный резерв по скорости — в неиспользуемом коде, который всё равно загружается на каждой странице.
Второй источник задержек — избыточные пересчёты. Формула, которая обращается к серверу при каждом изменении любого поля, легко превращает форму в источник десятков запросов. Такие места видно в панели разработчика: если при вводе одного символа улетает запрос, схему зависимостей нужно пересматривать.
Что это даёт заказчику
Заказчику не важно, каким способом описано состояние экрана. Ему важны две вещи: сколько стоит добавить новое правило и как часто в расчётах появляются ошибки. Реактивная схема на сложном экране улучшает обе цифры — новое условие добавляется точечно, а расхождения между связанными значениями исключены самим устройством кода. На простом экране она не улучшает ничего, зато добавляет к странице библиотеку и требует более дорогого разработчика на сопровождении.
Практическое правило
Мы применяем простой критерий. Если на экране больше пяти связанных величин и они меняются по действиям пользователя, реактивный подход окупается уже на первом же изменении требований. Если это страница с текстом и одной формой, он добавит сложности без выигрыша. Смешанная схема, где сайт сделан обычными средствами, а сложный экран — корзина, калькулятор, кабинет — собран реактивно, встречается чаще всего и обычно оказывается самой дешёвой в сопровождении.
Нужна помощь
Мы делаем и обычные сайты, и сложные интерфейсы с расчётами, фильтрами и личными кабинетами, подбирая подход под конкретный экран, а не под моду. Если у вас есть калькулятор или конфигуратор, в котором «иногда неправильно считается», посмотрим устройство и предложим решение. Обсудить разработку сайта можно с оценкой объёма работ.
