Практический пример раздутого компонента
Мы всегда так взволнованы новыми блестящими вещами, которые появляются каждую неделю в мире программирования. Новые способы структурирования компонентов, новые методы сокращения этих двух строк кода и так далее.
Но в реальном мире все не так радужно. Часто нам приходится иметь дело с кодовыми базами, которые развиваются на протяжении многих лет, и многие разработчики оставили свой след в разных частях компонента.
Наша история о компоненте с 2700 строк кода. Давайте попробуем объяснить, как дела пошли наперекосяк и как мы можем добиться большего.
Фон
Я работал в компании с инструментальной панелью управления автопарком, показывающей транспортные средства, перемещающиеся по городу в режиме реального времени.
Компонент панель управления — герой нашего сегодняшнего рассказа. Он имеет множество функций. Впрочем, ничего особенного.
- Карта, показывающая маркеры транспортных средств
- Способ поиска среди транспортных средств
- Всплывающее окно, которое показывает детали автомобиля при нажатии
- Список транспортных средств внизу
- Некоторые параметры фильтрации.
Конечно, есть несколько функций, за отображение которых отвечает этот единственный компонент. Но неужели это так много, чтобы содержать 2700 строк кода?
Компонент
Очевидно, я буду глуп, если вставлю в эту статью 2700 строк кода. (Кроме того, это будет незаконно :P ) Но позвольте мне показать вам общую структуру компонента.
Хорошо, теперь скажи мне, что здесь не так
Чтобы быть на 100% честным? Почти все. Позвольте мне объяснить это.
1. Постоянная декларация
Это такое очевидное. К сожалению, я видел много примеров этого во многих компаниях и во многих компонентах.
Вы должны хранить константы в отдельном файле
Неважно, используются они повторно или нет. Их все же лучше хранить в отдельном файле. Потому что в будущем кто-то другой создаст отдельную константу с тем же значением, что в конечном итоге создаст путаницу.
Я делаю это так.
А затем импортируйте внутри моего компонента и используйте их.
Этот конкретный компонент не имеет большого значения, но лучшие практики есть лучшие практики.
2. Стили и вспомогательные методы
Я думаю, что это очень распространенная ошибка (иногда допустимая) для небольших компонентов помещать стили и вспомогательные методы в один и тот же файл.
Если ваш компонент состоит всего из 30–50 строк кода, то имеет смысл хранить стили и вспомогательные методы в одном файле.
Но наличие 580 строк объявления стиля не имеет смысла ни при каких сценариях. Потому что не очень часто вам нужно было бы прикасаться к этим стилям.
Что я делаю, так это следую следующей структуре папок, чтобы все было организовано.
-component-name |-- __tests__ |-- styles.ts |-- helpers.ts |-- index.ts
Ответственность файлов понятна из названия самих файлов. Так просто просто разделить наш массивный компонент на 1/3 от его текущего размера, просто разместив вещи там, где они должны быть!
Пример
Если вы используете Raw CSS или SCSS, то вы, вероятно, не совершаете эту ошибку, но проекты, использующие styled-components
или material-ui
, в основном следуют этой плохой практике.
Однажды кто-то начал. Это стало стандартной практикой.
Так что не попадайтесь в эту ловушку. Заранее создайте отдельный файл для стилей, чтобы сохранить ваш компонент в будущем.
3. Глупые компоненты
Существует два типа компонентов.
- Тупые компоненты -› действуют только как контейнер или представление
- Интеллектуальные компоненты -> Показывает что-то на основе некоторой логики
Теперь нет смысла размещать два компонента в одном файле. Это прямо нарушает принцип единственной ответственности.
Каждый класс или компонент должен делать одну и только одну вещь
Иногда мы ленимся (в том числе и я) и помещаем простые компоненты-контейнеры в реальный компонент. Но что вы думаете, когда придет следующий разработчик?
Вынимает ли он меньший компонент в отдельный файл?
Эмм… Наверное, нет. Итак, через 4–5 лет у вас теперь есть 200 строк вспомогательных тупых компонентов, которые можно легко извлечь из отдельных файлов.
4. Компонент класса
Не уверен, заметили ли вы, но этот массивный компонент использует ClassComponent. Я уверен, что вы знаете причину. Он был написан в то время, когда функциональные компоненты не были так распространены.
Но в настоящее время использование функциональных компонентов имеет больше смысла, потому что
- Они просты в обслуживании
- Меньше кода
- Более производительный? (Возможно)
Но даже я бы не стал на данном этапе превращать его в функциональный компонент. Нам нужно провести рефакторинг многих вещей, прежде чем превратить это в функциональный компонент.
Посмотрим, сколько мы сможем получить.
Позвольте мне показать вам оценку того, насколько мы можем улучшить, даже не понимая, что делает этот компонент.
Мы можем просто экспортировать константы в constants.ts
, стили в styles.ts
и вспомогательные методы в файл helpers.ts
.
Styles = 600 Constants(Types+Others) = 100 Helper Methods. = 600 (roughly) Dumb Components = 200 --------------------------------- Total Gain = 1400 lines!
Это работа максимум на два часа. Все, что нам нужно сделать, это.
Помещение вещей в соответствующие файлы и их импорт
Мы можем уменьшить компонент с 2700 до 1300 строк!
Кто-то может сказать, что это все еще много. Но эй!!! Шаг за шагом, верно?
Можем ли мы сделать лучше?
Да, конечно. Когда мы изучаем внутреннюю логику, мы можем добиться еще большего.
- Разбейте фактические компоненты и детали многократного использования на еще более мелкие компоненты.
- Использование функционального компонента
- Использование крючков
- Использование функционального редукса
И так далее….. Но это уже другая история.
Покажи мне хорошие стороны.
Очевидно, что у этого компонента есть много проблем, но есть и хорошие вещи.
Машинопись
Хотя объявления Type занимают в общей сложности около 200 строк, они того стоят. Особенно без Typescript было бы невозможно поддерживать этот компонент.
Извлечение логики
Часть глупой логики извлечена из самой логики представления. Например, отображение сообщения в зависимости от состояния автомобиля.
Лучше иметь их в отдельной функции, вместо того, чтобы писать логику в представлении. Что может выглядеть примерно так…
Так что не все так плохо; некоторые разработчики пытались сделать все правильно. В конце концов, разработка программного обеспечения — это командная работа.
Чему я научился?
Самый важный вывод для меня — понять важность следования лучшим практикам.
Лучшие практики существуют не просто так
Влияние следования передовым методам может быть неочевидным в первый день, но если вы не будете следовать им, то однажды почувствуете боль!
Заключение
Надеюсь, вы сегодня узнали что-то новое. Хорошего дня!
Эта статья изначально была опубликована здесь.