Лучшие практики, которые помогут вам!
Широко используйте защитные оговорки
По мере роста строк кода увеличивается и вероятность поломки вашего приложения. С самого первого дня важно защищаться от этого. Один крутой трюк из старых времен программирования - это защитная оговорка.
Когда функция render в React возвращает null, компонент просто не отображается. В этом примере использование предложения guard позволит избежать ошибок в дальнейшем, если что-либо еще в render зависит от this.props.user, установленного на что-то иное, чем undefined, например объект пользователя.
В идеале проверка должна быть выше в иерархии компонентов, но часто мы живем не в идеальном мире. Использование защитных оговорок для раннего освобождения под залог, если переменные являются неожиданными или установлены неправильно, - отличный способ избежать ошибок у ваших пользователей.
Организация функций компонентов
Компоненты React обычно имеют две разновидности функций: встроенные функции жизненного цикла компонентов и функции, которые вы пишете сами. Убедитесь, что у вас есть четкий и последовательный способ организации этих функций в коде, поскольку это упростит чтение (и исправление) вашей кодовой базы.
На не немых компонентах я обычно помещаю constructor в самом верху (после объявления класса). Затем я добавлю все функции жизненного цикла компонентов (кроме render) после конструктора в алфавитном порядке. После этого я добавлю префикс _ к функциям, не относящимся к жизненному циклу, которые я пишу сам, например обработчикам изменений. Они также расположены в алфавитном порядке. Наконец, файл компонента .es6 будет заканчиваться функцией render, так как это первое место, где я буду искать ошибку.
Вы можете организовать функции своего компонента по своему усмотрению, но убедитесь, что он согласован. Наличие стандартной организации и файловой структуры упрощает чтение и анализ кодовой базы.
Знайте, что делает super ()
В конструкторе super() - одно из тех волшебных заклинаний, которые заставляют все работать. Но важно знать, что делает super и откуда он берется.
Вкратце, использование super() делает ключевое слово this доступным в вашем конструкторе, а super(props) делает this.props доступным в вашем конструкторе.
Остерегайтесь ошибок при назначении состояния из реквизита
В хорошо организованной кодовой базе значения state и props должны быть независимыми друг от друга. Но вы не можете контролировать все, и иногда вы попадаете в такую ситуацию:
Где мы можем ошибиться здесь?
Обратите внимание, что состояние присваивается только один раз при создании компонента. Что происходит с состоянием этого компонента, когда foo или bar реквизиты обновляются в родительском компоненте? Ничего такого.
Если вы назначаете значения в состоянии из значений в свойствах, вы должны отслеживать изменения свойств и соответственно обновлять состояние.
В 9 случаях из 10 в вашем компоненте также должен использоваться метод жизненного цикла componentWillReceiveProps, чтобы предотвратить рассинхронизацию состояния и свойств.
Здесь, конечно же, есть своя ошибка - получить - трудное слово для написания.
Используйте подробные имена компонентов
Как разработчики, у нас есть ограниченное количество нажатий клавиш, которые мы можем сделать перед смертью. Хотя может показаться прагматичным сохранять эти нажатия клавиш для написания фактического кода вместо длинных имен компонентов, этот подход оказывается недальновидным при попытке реорганизовать код два месяца спустя.
Легко представить себе несколько циклов разработки и обратной связи, в которых имя компонента меняется с Nav на SideNav, с DashboardSideNav на DashboardLoggedInSideNav. Почему бы не начать разработку с максимально подробного имени компонента и сэкономить время на рефакторинге имен в будущем?
Кроме того, использование подробных имен компонентов заставляет вас придумать общий словарь местоположений страниц и связанных с ними виджетов. Этот общий словарь может использоваться совместно с CSS и JS, что делает вашу кодовую базу более читаемой. А подробные, явные имена компонентов значительно упрощают переход к кодовой базе и начало ее изменения за счет сокращения времени, затрачиваемого на отслеживание исходных файлов из скомпилированных выходных данных внешнего интерфейса.
Переменная с именем _
Не тратьте время на обдумывание названий одноразовых переменных. Выберите общее имя для переменных, которые просто содержат данные, которые нужно преобразовать в дальнейшем.
Вы не только сэкономите себе несколько мысленных циклов, думая об имени переменной, вы укажете другим разработчикам, что переменная _ - это всего лишь одноразовая переменная и не имеет такого большого значения. В некоторых языках, таких как Go, эта идея встроена.
Один крутой трюк для обработчиков изменений
Когда дело доходит до компонентов контролируемой формы, может быть обременительным написать обработчик изменений для каждого ввода from. К счастью, назначив атрибут name входу, который мы хотим изменить, мы можем создать очень общий обработчик изменений.
Когда срабатывает событие изменения, атрибут name становится доступным для цели события, что упрощает назначение правильного свойства в state в зависимости от того, от какой цели произошло событие.
Прочтите файл Readme
Это, наверное, самый важный совет здесь. Readme - это единый документ, описывающий приложение. Наличие шаблона или пустого файла readme - это небрежная разработка.
Хороший файл readme предназначен для коллег-разработчиков. Он содержит инструкции о том, как запустить приложение в первый раз, документацию по процессу развертывания и заметки по архитектуре. Включите команды копирования и вставки для часто выполняемых операций. Включите этапы жизненного цикла кода: как фиксация попадает в рабочую среду.
Это нормально, если ридми охватывает широкий круг косвенно связанных тем (вроде этого сообщения). Ридми должен быть одним из первых знакомств с новым и загадочным приложением и должен стремиться объяснить как можно больше.
