desyatnikov.dev / journal
← Все заметки
Frontend / 3 мин ЧТЕНИЯ

Сначала состояния. Потом компоненты.

Небольшая практика, которая делает сложный экран проще: описать его поведение до выбора UI-библиотеки.

Начните с переходов

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

Ошибка не всегда блокирует работу

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

Типы помогают не забыть варианты

В TypeScript объединение с различающим полем позволяет описать допустимые состояния явно. Это не заменяет проектирование, но делает забытый случай заметнее при изменении кода.

Разделяйте данные и представление

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

Сценарий важнее количества компонентов

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

Конец заметки.К другим материалам ↗