Найти тему
Фронтенд

Рефакторинг. Состояния и статический маппинг

Оглавление

Во время разработки встречаются случаи с перечислением сложных условий и состояний внутри компонента.

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

Давайте рассмотрим условный пример реализации формы с множеством экранов:

Самое простое и популярное решение — использовать switch-case. Это наглядная и понятная структура, но в остальном выглядит громоздко.

Так же нужно объявлять функцию не очевидно как сделать мемоизацию (через useMemo или useCallback). Если нужно добавить условие в какой-то кейс, срока заметно увеличивается в размере

Рендер формы с различными экранами на switch-case
Рендер формы с различными экранами на switch-case

Теперь перепишем на статический маппинг, где значение ключа соответствует значению компонента и условию:

Рендер формы с различными экранами через статический маппинг
Рендер формы с различными экранами через статический маппинг

Мы избавились от бойлерплейта, объект выглядит проще. Перед значением можно не писать дополнительное условие. Декларативность не только сохраняется, но и улучшается.

Итог

Такие мелочи позволяют писать более простой и понятный код, его легко поддерживать и читать. Знание таких подходов отличает начинающего разработчика от опытного.

Ошибки?

Если вы обнаружили ошибку в тексте статьи или вам есть что добавить, пожалуйста напишите об этом в комментариях. Спасибо!