Пора положить конец спагетти-коду.
Всякий раз, когда я заканчиваю сборку проекта или смотрю на какой-нибудь старый код, я всегда стараюсь найти способы его рефакторинга и улучшения читабельности. Способы сделать это могут включать в себя написание пользовательских перехватчиков React, перенос повторяющегося кода в подпрограммы и другие. В этой статье я расскажу о трех общих методах модульности и повышения удобства сопровождения вашего кода. Давайте погрузимся.
1. Используйте TypeScript
Для некоторых это может вызвать раздражение, но TypeScript устраняет многие проблемы, которые в некоторых случаях делают JavaScript небезопасным языком. Это также проясняет намерения вашего кода. Давайте посмотрим на пример JavaScript простого компонента React People:
Здесь мы видим, что People принимает peopleList в качестве реквизита, который представляет собой список объектов, каждый из которых представляет человека, который будет отображаться как <ListItem />. Все это нормально, но что, если собственность отсутствует у кого-то из людей? Что делать, если человек имеет undefined в качестве профессии или зарплаты? Многие из вас могут подумать, что мы можем просто использовать prop-types, чтобы справиться с этим, но, на мой взгляд, TypeScript предоставляет более элегантное решение. Давайте посмотрим на тот же People компонент, написанный на TypeScript:
В этом примере мы определили интерфейс Person с необязательными свойствами (, обозначенными?), Чтобы сообщить компилятору, что человек в peopleList может содержать только подмножество свойств в Person. Мы также определили PeopleProps интерфейс, который определяет тип опоры, которую People должен получить, то есть массив Person. В результате компонент People стал более гибким и надежным.
2. Используйте IIFE
Если вы знакомы с выражениями мгновенно вызываемых функций (IIFE), то вы определенно знаете, насколько они могут быть полезны как простой способ объединить два оператора в один. Допустим, вы хотели инициализировать массив некоторыми внешними данными:
В этом примере мы определили функцию initList, которая возвращает массив, содержащий внешние данные. Затем мы вызываем функцию и сохраняем результат в dataList. Не то чтобы с этим кодом что-то не так, но его можно было бы написать более элегантно, например:
Здесь мы экономим несколько строк, назначая dataList анонимной функции, которая вызывается немедленно.
3. Разделение проблем
Всегда важно разделять проблемы функциональности в кодовой базе, особенно при работе с проектами возрастающей сложности. Обычно не идеально, когда функция выполняет несколько задач одновременно, особенно если они не связаны друг с другом. Давайте проанализируем плохой пример React компонента Example, который зависит от некоторых внешних данных API:
Причина, по которой это плохой пример, заключается в том, что компонент Example должен отвечать только за отображение данных на экране, а не за выборку внешних данных. Это создает беспорядок и затрудняет отладку компонента. К счастью, мы можем исправить это, написав наш собственный хук, который содержит логику для создания почтового запроса. Этот хук будет функцией, которая принимает URL-адрес и параметры, выполняет почтовый запрос и возвращает следующие данные:
Теперь, когда вся логика для вызова API находится в этом настраиваемом хуке, наш компонент Example теперь выглядит так:
С usePost абстрагированием логики почтового запроса компонент Example теперь отвечает только за отображение данных. Благодаря этому изменению кодовая база стала намного более удобной в обслуживании.
Если вы сделали это здесь, спасибо за чтение! Надеюсь, вы нашли этот пост поучительным. Наслаждайтесь остатком дня.
Больше контента на plainenglish.io
