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