Как бы ты декомпозировал сложный экран на логические части?

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

1) Начало декомпозиции — не код, а сценарии

Перед тем как писать или рефакторить код, важно ответить на вопросы:

1. Какие пользовательские сценарии есть у экрана?

2. Какие состояния экран может иметь?

3. Что является бизнес-логикой, а что — отображением?

Пример сценариев:

• первый вход;

• загрузка данных;

• ошибка;

• пустое состояние;

• пользовательское действие (поиск, фильтр, отправка формы).

2) Выделение состояний экрана

Практически любой сложный экран можно описать через ограниченный набор состояний.

Типовой подход:

enum ScreenState {
    case loading
    case content(ContentModel)
    case empty
    case error(String)
}

Что это дает:

1. Убирает хаотичные флаги (isLoading, hasError, shouldReload).

2. Делает UI детерминированным.

3. Упрощает тестирование логики.

3) Разделение UI на логические блоки

После состояний экран делится на независимые части.

Примеры логических блоков:

1. Header (заголовок, фильтры, поиск).

2. Content (список, форма, карточки).

3. Footer (кнопки, итоги).

4. Overlays (loader, error, empty state).

Практика:

• каждый блок — отдельный UIView или компонент;

• блок не знает о данных других блоков;

• блок получает только то, что ему нужно для отображения.

4) Вынос бизнес-логики из view controller

Сложный экран почти всегда содержит:

• преобразование данных;

• валидацию;

• условия отображения;

• реакции на события.

Эта логика не должна жить в контроллере.

Обычно выносят:

1. В ViewModel / Presenter — если используется MVVM/VIPER.

2. В отдельные use case / service — если логика общая.

3. В отдельные модели состояния.

Контроллеру остается:

• подписка на состояние;

• рендер UI;

• проксирование пользовательских действий.

5) Отделение навигации

Навигация — отдельная ответственность.

Антипаттерн:

• контроллер сам создает следующий экран;

• передает зависимости;

• решает, как именно переходить.

Хорошая практика:

1. Навигация вынесена в координатор / роутер.

2. Контроллер сообщает что произошло, а не куда идти.

6) Управление асинхронностью

При декомпозиции важно:

1. чтобы асинхронность была централизована;

2. чтобы экран не знал деталей сети;

3. чтобы отмена была управляемой.

Часто это означает:

• асинхронность в ViewModel;

• state как единственный источник правды для UI.

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

Декомпозиция сложного экрана — это последовательный процесс: сценарии → состояния → UI-блоки → бизнес-логика → навигация. Чем раньше экран разбит на независимые части с четкими границами, тем проще его развивать и поддерживать.