Лучшие практики в приложениях React
12 вещей, которые нельзя делать при создании приложений React с Redux
Чего следует избегать, исходя из моего опыта работы на производстве
Когда вы создаете приложения React, небольшие проекты часто могут быть немного более гибкими, чем большие проекты, когда дело касается архитектуры кода. Хотя на самом деле нет ничего неправильного в том, чтобы создать небольшое приложение в соответствии с передовыми практиками, предназначенными для более крупных приложений, возможно, нет необходимости принимать важные решения. Чем меньше приложение, тем лучше становится лениться.
Однако лучшие практики в этой статье предназначены для приложений React любого размера.
Если у вас никогда не было опыта создания приложения в рабочей среде, эта статья поможет вам подготовиться к этому. Худшее, что может случиться с вами, - это создание приложения на вашей работе, только чтобы понять, что вам нужно реорганизовать большие объемы кода, чтобы сделать его более масштабируемым и поддерживаемым, особенно если вам не хватает модульных тестов !
Поверьте мне. Я был там. Мне бесчисленное количество раз говорили заполнить x на y. Сначала мне показалось, что все идет гладко и великолепно. Я думал, что только потому, что мое веб-приложение работало и чувствовал себя быстрым, я отлично справлялся с разработкой и сопровождением своего кода. Я знал, как использовать Redux и заставить компоненты пользовательского интерфейса взаимодействовать друг с другом, как ожидалось. Редукторы и действия были для меня легкой концепцией. Я чувствовал себя непобедимым.
Пока не подкралось будущее.
Спустя пару месяцев и более 15 функций ситуация вышла из-под контроля. Мой код, использующий Redux, больше не было легко поддерживать.
«Почему?» - спросите вы.
«Разве вы не были непобедимы?»
Ну я тоже так думал. В итоге это превратилось в бомбу замедленного действия, ожидающую катастрофы. Redux обладает удивительной способностью поддерживать ремонтопригодность при правильном использовании в крупномасштабном проекте.
Прочтите, чтобы узнать, чего не делать, если вы планируете создавать масштабируемые веб-приложения на React.
1. Размещение действий и констант в одном месте
Вы можете увидеть несколько руководств по Redux, в которых константы и все действия помещаются в одно место. Однако это может быстро стать проблемой, когда приложение станет больше. Константы должны находиться в отдельном месте, например ./src/constants, чтобы было одно место для поиска, а не несколько.
В любом случае, безусловно, нормально создать отдельный файл действий, представляющий с чем или как он будет использоваться, инкапсулируя непосредственно связанные действия. Если вы создавали новую аркадную / ролевую игру и включали в нее классы персонажей воин, колдунья и лучник, ее было бы намного легче поддерживать. если вы разместили свои действия так:
src / actions / warrior.js
src / actions / sorceress.js
src / actions / archer.js
Скорее, чем что-то вроде:
src / actions / classes.js
Если приложение становится огромным, вероятно, лучше использовать что-то вроде этого:
src / actions / warrior / skills.js
src / actions / sorceress / Skills.js
src / actions / archer / skills.js
Если бы это был реальный сценарий, общая картина могла бы быть примерно такой, если бы мы организовали их таким образом:
src / actions / warrior / skills.js
src / actions / warrior / quests.js
src / actions / warrior / equipping.js
src / actions / sorceress / skills. js
src / actions / sorceress / quests.js
src / actions / sorceress / equipping.js
src / actions / archer / skills.js
src / actions / archer / quests.js
src / actions / archer / equipping.js
Пример того, как будут выглядеть действия колдуньи:
src / actions / sorceress / навыки
src / actions / sorceress / экипировка
Причина, по которой мы это делаем, заключается в том, что, скорее всего, всегда будут добавляться новые функции, и вы должны подготовиться к ним, поскольку ваши файлы станут более раздутыми!
Поначалу это может показаться излишним, но эти подходы начнут проявляться по мере того, как проект становится больше.
2. Размещение редукторов в одном месте
Когда мои редукторы начинают выглядеть так:
Очевидно, что большой беспорядок может быть создан очень быстро, поэтому лучше сделать структуру состояния простой и как можно более плоской или вместо этого попытаться скомпоновать все свои редукторы.
Изящный трюк состоит в том, чтобы создать редуктор более высокого порядка, который генерирует редукторы, сопоставляя каждый завернутый редуктор с отображением объекта от типов действий к обработчикам.
3. Неправильное название переменных
Присвоение имен вашим переменным звучит как легкая задача, но на самом деле это может быть одна из самых сложных вещей, в которых нужно хорошо разбираться в написании кода.
По сути, это чистая практика кодирования, и причина, по которой этот термин вообще существует, заключается в том, что его так важно применять на практике. Плохое обозначение переменных - хороший способ позволить членам вашей команды и самому себе в будущем страдать!
Вы когда-нибудь пытались редактировать чужой код и в конечном итоге с трудом понимали, что пытается делать этот код? Вы когда-нибудь запускали чей-то код, и он работал не так, как вы ожидали?
Готов поспорить, что автор кода применял методы грязного кода.
Худшая ситуация - это пройти через это в большом приложении, где это происходит в нескольких областях.
Позвольте мне дать вам реальный опыт ситуации, в которой я оказался:
Когда мне дали задание добавить и показать дополнительную информацию о каждом докторе в списке таблиц, я начал редактировать существующий хук React из кода приложения. В то время, когда они выбирали (нажимали) врача, информация о нем сохранялась в некотором состоянии, чтобы мы могли отправить информацию при следующем запросе API.
Все шло хорошо, за исключением того, что я тратил больше времени, чем следовало бы, на поиск где эта часть в коде.
В этот момент в моей голове я искал такие слова, как info, dataToSend, dataObject, doctorProfile или что-нибудь, относящееся к к только что собранным данным. Через 10–15 минут я обнаружил, что часть, в которой реализован этот поток, и объект, в который он был помещен, были названы paymentObject. Когда я думаю об объектах оплаты, я думаю о CVV, последних 4 цифрах, почтовом индексе и т. Д. Из 11 свойств только три были связаны с оплатой: метод начисления , идентификатор платежного профиля и купоны.
И не помогло то, что потом было слишком неловко вносить мои изменения.
Короче говоря, постарайтесь воздержаться от именования ваших функций или переменных следующим образом:
4. Изменение структуры данных / типов на полпути
Одна из самых больших ошибок, которые я когда-либо делал, заключалась в изменении структуры данных / типов чего-либо во время уже установленного потока приложения. Новая структура данных была бы огромным приростом производительности, поскольку она использовала поиск объектов для захвата данных в памяти вместо сопоставления массивов. Но было слишком поздно.
Не делайте этого, если вы действительно не знаете все области, которые будут затронуты.
Какие есть последствия?
Если что-то изменится из массива в объект, несколько областей приложения рискуют стать нефункциональными. Я совершил самую большую ошибку, подумав, что каждая часть приложения, на которую может повлиять запланированное изменение структурированных данных, было запланировано в моей голове, но всегда останется это одно место. что было упущено.
6. Разработка без использования фрагментов
Раньше я был поклонником Atom, но я переключился на VScode, поскольку он предоставлял функции, которые я считаю очень ценными в процессе разработки, такие как Project Snippets.
Если вы используете VSCode, я настоятельно рекомендую вам скачать его, если вы еще этого не сделали. Это расширение позволяет вам объявлять пользовательские фрагменты для каждой рабочей области этого проекта. Он работает точно так же, как встроенная функция пользовательских фрагментов, которая по умолчанию входит в VScode, за исключением того, что вы создаете папку .vscode/snippets/ внутри своего проекта следующим образом:
7. Игнорирование тестов Unit / E2E / Integration
По мере роста приложения становится все страшнее редактировать существующий код без каких-либо тестов. Вы можете в конечном итоге отредактировать файл, расположенный в src / x / y / z /, и решить отправить изменения в рабочую среду, однако, если изменение затронет другую часть приложения, которую вы не заметили, ошибка останется там до тех пор, пока не появится настоящий пользователь ловит его во время просмотра, так как у вас не будет никаких тестов, чтобы предупредить вас заранее.
8. Пропуск фазы мозгового штурма
Разработчики часто пропускают фазу мозгового штурма, потому что они не занимаются программированием, особенно когда им дается неделя на разработку функции. Однако, по опыту, это наиболее важный шаг, который сэкономит вам и вашей команде много времени в будущем.
Зачем устраивать мозговой штурм?
Чем сложнее приложение, тем больше разработчиков должно управлять определенными частями приложения. Мозговой штурм помогает сократить количество рефакторинга кода, потому что вы уже спланировали, что может пойти не так. Часто разработчикам не дается время расслабиться и применить все полезные приемы для дальнейшего улучшения приложения.
Вот почему так важен мозговой штурм. Вы думаете обо всем, что касается дизайна кода в архитектуре, и тех улучшениях, которые вам потребуются, поэтому вы можете решать их все с самого начала, применяя стратегический подход. Не входите в привычку быть излишне самоуверенным и все продумывать в уме. В противном случае вы не сможете запомнить все. Как только вы сделаете что-то не так, все пойдет не так, как эффект домино.
Мозговой штурм облегчит задачу и вашей команде. Если один из них когда-либо застревает на задаче, он может сослаться на мозговой штурм, который у них был с самого начала, и, возможно, он уже там.
Заметки, которые вы делаете в ходе мозгового штурма, также могут послужить вам и вашей команде в качестве повестки дня и помогут легко обеспечить единообразное представление о вашем текущем прогрессе при разработке приложения.
9. Отсутствие предварительного определения компонентов пользовательского интерфейса
Если вы собираетесь начать разработку своего приложения, вам следует решить, как вы хотите, чтобы ваше приложение выглядело и чувствовалось. Доступны несколько инструментов, которые помогут вам в создании ваших собственных макетов.
Один из инструментов создания макетов, о котором я часто слышу, - это Moqups. Он быстрый, не требует дополнительных модулей и построен на HTML5 и JavaScript.
Выполнение этого шага очень полезно, поскольку дает вам как информацию, так и данные, которые будут находиться на создаваемых вами страницах. Разработка вашего приложения будет намного проще.
10. Отказ от планирования потока данных
Почти каждый компонент вашего приложения будет связан с какими-то данными. Некоторые будут использовать собственный источник данных, но большинство из них будет предоставляться из более высокого места в дереве. Для частей вашего приложения, где данные используются более чем одним компонентом, рекомендуется сделать эти данные доступными выше в дереве, где они будут действовать как централизованное дерево состояний. Здесь на помощь приходит мощь Redux :)
Я советую составить список того, как данные будут передаваться в вашем приложении. Это поможет вам создать прочную мысленную и письменную модель вашего приложения. Исходя из этих значений, ваш редуктор должен легко устанавливаться из него.
11. Отказ от функций доступа
По мере увеличения размера приложения увеличивается и количество компонентов. И когда количество компонентов увеличивается, увеличивается и количество раз, когда вы используете селекторы (response-redux ^ v7.1) или mapStateToProps. Если вы обнаружите, что ваши компоненты или хуки часто выбирают срезы состояния, такие как useSelector ((state) = ›state.app.user.profile.demographics.languages.main), в нескольких частях вашего приложения, пришло время начать думать о создании функций доступа в общем месте, откуда компоненты / хуки могут импортировать и использовать. Эти функции доступа могут быть фильтрами, синтаксическими анализаторами или любыми другими функциями преобразования данных.
Вот некоторые примеры:
src / accessors
подключить версию
src / components / ViewUserLanguages
Версия useSelector
src / components / ViewUserLanguages
Также очень важно, чтобы эти функции были неизменными и не имели побочных эффектов, как описано здесь.
В качестве альтернативы другим популярным решением является повторный выбор, специально созданный и оптимизированный для redux, как описано здесь. Если вы будете использовать его так же, как любую из функций-аксессоров, упомянутых выше, вы получите дополнительное преимущество в виде кэширования вычисленных значений, когда эти функции будут только повторно вычисляться при изменении одного из своих аргументов. Чем более дорогостоящие вычисления у вас есть в ваших компонентах, тем более настоятельно рекомендуется это решение. (спасибо, healqq).
12. Отсутствие контроля над потоком в Props с атрибутами Destructuring и Spread.
Каковы преимущества использования props.something по сравнению с something?
Без деструктуризации:
const Display = (props) => <div>{props.something}</div>const Display = ({ something }) => <div>{something}</div>
С деструктуризацией вы не только делаете свой код более читабельным для себя и других, но также принимаете прямые решения о том, что входит, а что выходит. Когда другие разработчики редактируют ваш код в будущем, им не нужно сканировать каждую строку кода в вашем методе рендеринга, чтобы найти все реквизиты, которые использует компонент.
Вы также получаете выгоду от возможности объявить опору по умолчанию с самого начала без необходимости добавлять какие-либо строки кода:
const Display = ({ something = 'apple' }) => <div>{something}</div>Возможно, вы видели что-то подобное раньше:
Это не только немного сложнее для чтения, но и в этом компоненте возникает непреднамеренная ошибка. Если App также обрабатывает дочерние элементы, значит, props.children обрабатывается дважды. Это вызывает дубликаты. При работе с командой разработчиков помимо вас есть вероятность, что эти ошибки могут произойти случайно, особенно если они недостаточно осторожны.
Вместо этого деструктурируя props, компонент может перейти прямо к делу и снизить вероятность нежелательных ошибок:
Прочтите: 10 вещей, которые НЕ следует делать при создании приложений на React
Заключение
Вот и все, ребята! Надеюсь, эти советы вам помогли. Не стесняйтесь писать мне комментарий / сообщение с любыми вопросами и / или проблемами! Увидимся в следующий раз!
