TGViewer
Катерина | Про Frontend Катерина | Про Frontend @katerina_profrontend · 2.87K subscribers
Post #1555 1.57K
Почему бизнес-логику не стоит писать в UI-компонентах 🧐

Часто вижу один и тот же паттерн: небольшой компонент, пара условий — и через несколько фич он превращается в монстра, который и отображает, и решает, и общается с API, и ещё немного «магии» делает. 🤯 В итоге вместо чистого UI у нас — куча скрытой логики, которую потом тяжело поддерживать.

🧩 Как же так получается?

Сначала всё выглядит логично: дедлайн, фича маленькая — проще вставить обработку прямо в компонент. Потом «потом вынесем» не наступает, и компонент растёт:

➖ вызывает API и трансформирует ответы;
➖решает, какие шаги процесса выполнять;
➖содержит ветвления бизнес-правил;
➖становится источником копипаста при переиспользовании.

🧩 А в чём же здесь проблема?

☑️ Роли смешиваются. Компонент должен показывать интерфейс, а не управлять процессом. Когда UI начинает «думать», система становится довольно хрупкой;
☑️ Переиспользование погибает. Нужна та же логика в другом месте — копипаст, рассинхронизация, баги;
☑️ Изменения рискованны. Поправил отображение — сломал процесс; поменял правило — неожиданно упало UI;
☑️ Тестирование усложняется.

🧩 Почему же пишут логику в компонентах?

⏺️ Быстрее на старте;
⏺️ "Кажется" избыточным выносить «для одной фичи»;
⏺️ Команда устала/нет архитектурного стандарта.

Но чаще бывает так, что «маленькая фича» обычно вырастает, и технический долг накапливается. 😥

🧩 Как же лучше стараться организовать код?

Разделение обязанностей простое и эффективное:

✔️ UI-компоненты — отвечают за отображение и реагирование на пользовательские действия;

✔️ Бизнес-логика — в сервисах, сторе илимодулях;

✔️ Интеграция — компоненты вызывают сервисы/экшены и получают уже готовые данные/состояния.


Примерный поток: компонент → action/use-case → сервис → репозиторий/API → сервис → use-case → компонент (обновлённый state).

🧩 Как же можно себя проверить?

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


Как итог, UI — это слой отображения, бизнес-логика — слой принятых решений. Смешивать их удобно только на старте, но в долгой перспективе это почти всегда приводит к росту сложности, хрупкости системы и технического долга. 🙈
  • 👍 19
  • 🔥 9
More from @katerina_profrontend
  1. Feb 22, 2026Когда height: 100% чуть-чуть поломало вёрстку 🙈 Я делала простую сетку: контейнер display…
  2. Feb 20, 2026Разбираемся с Proxy в JavaScript 👨‍🏫 Proxy — посредник между кодом и объектом. Он перехв…
  3. Feb 17, 2026Compression Streams API — нативный gzip/deflate прямо в браузере 🤔 Недавно снова вспомнил…
  4. Feb 6, 2026Как неочевидные импорты превращают проект в клубок зависимостей 😨 На бумаге — простое пра…
  5. Feb 2, 2026«Хочу стиль для p в header, но не хочу повышать специфичность» 😎 Иногда самая тривиальная…
  6. Jan 29, 2026Связность и сцепленность: как написать код, который не боишься менять 🧩 Представьте проек…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →