Практический пример раздутого компонента

Мы всегда так взволнованы новыми блестящими вещами, которые появляются каждую неделю в мире программирования. Новые способы структурирования компонентов, новые методы сокращения этих двух строк кода и так далее.

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

Наша история о компоненте с 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 было бы невозможно поддерживать этот компонент.

Извлечение логики

Часть глупой логики извлечена из самой логики представления. Например, отображение сообщения в зависимости от состояния автомобиля.

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

Так что не все так плохо; некоторые разработчики пытались сделать все правильно. В конце концов, разработка программного обеспечения — это командная работа.

Чему я научился?

Самый важный вывод для меня — понять важность следования лучшим практикам.

Лучшие практики существуют не просто так

Влияние следования передовым методам может быть неочевидным в первый день, но если вы не будете следовать им, то однажды почувствуете боль!

Заключение

Надеюсь, вы сегодня узнали что-то новое. Хорошего дня!

Эта статья изначально была опубликована здесь.