Во время разработки встречаются случаи с перечислением сложных условий и состояний внутри компонента.
Разработчики сталкиваются с этим при создании: форм с множеством экранов, компонентов с несколькими визуальными состояниями, сложной валидацией и роутингом.
Давайте рассмотрим условный пример реализации формы с множеством экранов:
Самое простое и популярное решение — использовать switch-case. Это наглядная и понятная структура, но в остальном выглядит громоздко.
Так же нужно объявлять функцию не очевидно как сделать мемоизацию (через useMemo или useCallback). Если нужно добавить условие в какой-то кейс, срока заметно увеличивается в размере
Теперь перепишем на статический маппинг, где значение ключа соответствует значению компонента и условию:
Мы избавились от бойлерплейта, объект выглядит проще. Перед значением можно не писать дополнительное условие. Декларативность не только сохраняется, но и улучшается.
Итог
Такие мелочи позволяют писать более простой и понятный код, его легко поддерживать и читать. Знание таких подходов отличает начинающего разработчика от опытного.
Ошибки?
Если вы обнаружили ошибку в тексте статьи или вам есть что добавить, пожалуйста напишите об этом в комментариях. Спасибо!