Сегодня я хочу поговорить о другом. Я хочу поделиться некоторыми советами и стратегиями, которые помогут вам писать более чистый и лучший код в React.
Большая часть того, что я написал или напишу в будущем, касается тех вещей, которые мне показались трудными, когда я учился программировать.
Мне, как разработчику-самоучке без наставника, одной из трудностей было написание чистого кода в react.
Я знаю, что мне нужно было поправиться. Но как?
Итак, я нашел решение. Найдите 5 уважаемых и профессиональных разработчиков реакции, перейдите в их репозиторий GitHub и найдите общий элемент или / или шаблон в их проекте реакции.
Я не пытался сравнивать свой код с чьим-либо. Я просто хочу узнать, что эти так называемые профессионалы добавляют в свой код, как они что-то реализуют, применяют подходы и почему.
Как и ожидалось, начали появляться вещи, которые отсутствуют в моем коде и присутствуют во всех пяти. Все начало обретать смысл. Например, зачем добавлять типы опор в рабочий процесс, если это не требуется.
TL;DR
С того дня я начал включать все, что узнал, в свой рабочий процесс. И поверьте, это помогло мне понять реакцию и сделало мой код не таким уж новичком.
Хватит разговоров. Я поделюсь некоторыми советами, извлеченными из моих исследований, а также теми, которые я узнал в ходе проектов и на собственном опыте.
Вот они в произвольном порядке.
1. Типы опор
Если вы новичок в реакции, возможно, вы не знаете, какие типы опор. Однако те, кто работал с react, хотя бы пару раз видели или работали с ним.
Какие бывают типы опор?
По сути, prop-types - это модуль / пакет или как бы вы его ни называли, который обеспечивает проверку типов для наших свойств.
Допустим, вы ожидаете, что родительский элемент поддерживает объект, и по какой-то причине вы получаете массив. Это вызовет полный хаос в вашем приложении, верно?
Вот где на сцену выходят типы реквизита. Вы определяете, какой тип опоры вы ожидаете, и если вы передадите что-то противоположное, это вызовет ошибку.
const App = ({title, id, isCompleted}) => {
//
}
App.propTypes = {
Id: PropTypes.number.isRequired,
title: PropTypes.string.isRequired,
isCompleted: PropTypes.bool.isRequired
}
В приведенном выше блоке кода у нас есть компонент app, который получает три свойства - title, isCompleted и id. И ниже мы определили наши проп-типы, заголовок должен быть строкой, id должен быть числом, а isCompleted должен быть логическим.
Если мы получим что-то противоречащее тому, что мы определили, мы получим ошибку. Это основной вариант использования проп-типов. Это может быть немного сложно, но со временем вы научитесь.
Вот ссылка на документацию по типам реквизитов
2. Используйте функциональные компоненты и хуки вместо классов.
Хорошо, это немного спорно. Кто-то может со мной согласиться, а кто-то нет. Я использовал классы и методы жизненного цикла, и если мне есть что сказать о них, это будет положительно.
Однако будущее React за функциональными компонентами и хуками. React делает все более благоприятным для хуков (инструменты разработки React подтвердят это утверждение).
На мой взгляд, если вы начинаете новый проект, используйте хуки и функциональные компоненты, но для существующих кодовых баз, построенных с помощью классов, не выполняйте рефакторинг.
Мне лично нравятся функциональные компоненты. То есть они чище, элегантнее и проще. Добавление их в рабочий процесс значительно очистит ваш код и сделает вас лучшим разработчиком React.
Использование функциональных компонентов и хуков показывает, что Разработчик может адаптироваться к экосистеме. Пару месяцев назад я прошел тест по кодированию на вынос в компании, которую я подал на работу. Я сделал весь проект на крючках, и интервьюер остался доволен, потому что «я иду в ногу со временем».
- * Скоро я напишу учебник по продвинутым хукам **
3. Делайте компоненты небольшими и многоразовыми, но не слишком абстрактными.
Одна из главных особенностей React - наличие всего в одном компоненте. Компоненты в react эквивалентны блокам Lego - небольшим фрагментам кода, которые создают приложение.
Ваши компоненты должны быть относительно небольшими. Например, раздел отправки в WhatsApp - это компонент, верно? Внутри этого компонента есть компонент кнопки отправки, компонент голосового сообщения и компонент текстовой области.
Все разбито на небольшие простые фрагменты кода. компоненты должны быть не только небольшими, но и многоразовыми. Я не говорю, что все компоненты должны быть повторно использованы, а только те компоненты, которые, как вы знаете, собираетесь снова использовать в другой части вашего приложения. Хорошим примером многократно используемого компонента является кнопка.
Если я хочу создать компонент кнопки, я сделаю его максимально универсальным. Размер, цвет и радиус границы будут переданы как реквизиты.
При этом не следует чрезмерно абстрагироваться от компонента. Под чрезмерной абстракцией я подразумеваю создание всех или большей части вашего компонента универсальным.
Помните, универсальный компонент - это компонент, который, как вы уверены, вы будете использовать более чем в одном месте.
4. Разрушить опоры. Больше никаких реквизитов.
Это один из моих выводов из проведенного мной исследования. Итак, до исследования мой код был похож на
const myApp = (props) =>{ ///<h1>{props.title.heading}</h1> onChange={props.onChange}}
Да, я знаю, уродливая задница. Хотя я не могу вспомнить, когда делал это в последний раз. Вот чем я сейчас занимаюсь.
Если реквизит всего на один уровень глубиной
const myApp = ({title, onChange}) =>{ /// Const {heading}= title<h1>{heading}</h1> onChange={onChange}}
И если он вложенный, например состояние redux, я делаю что-то вроде этого.
const myApp = ({chat:{messages}, settings:{themes}}) =>{ /// Const {sentMsg, recievedMsg}= messages Const {dark, light}= themes<h1> Theme color {dark}</h1> <li> {sentMsg} </li>}
Очевидно, что деструкция красивее и чище, чем выполнение props.title…. вещь.
Деструктуризация очищает ваш код реакции и делает его очень читабельным и снова чистым.
Вот и все, ребята! Надеюсь, вам это понравится, и вы чему-нибудь научитесь.
Оставайся в безопасности
