Перевод статьи Томаса Эглинскаса «The most important lessons I’ve learned after a year of working with React».


Начало работы с новой для вас технологией бывает весьма сложным. Вы вдруг оказываетесь окружены горами руководств и статей, а также подписками на кучу людей, высказывающих свое мнение. И везде сказано, что автор нашел «самый лучший и правильный подход».
Это погружает нас в пучину сомнений: а не является ли выбранный нами туториал напрасной тратой времени.
Прежде чем пуститься в открытое плавание, нам нужно понять идеи, лежащие в основе технологии. Затем нужно развить специфический взгляд на вещи, основанный на этой технологии. То есть, если мы начинаем изучать React, то мы должны научиться думать на языке React. И лишь потом можно будет начать комбинировать разные взгляды и подходы.
В этой статье я расскажу о некоторых усвоенных мной уроках в плане выработки этого особого взгляда на вещи. Все сказанное здесь основывается на моем личном опыте работы с React.
React не стоит на месте, так что нужно поспевать за ним
Вероятно, вы помните, как все были восхищены, когда вышел анонс версии 16.3.0. Среди изменений и улучшений, которые тогда появились, были:
- Official Context API
- createRef API
- forwardRef API
- StrictMode
- Изменение жизненного цикла компонента
Команда React и все участники проекта отлично поработали, стараясь усовершенствовать нашу любимую технологию. И в версии 16.4.0 появились события указателей.
Конечно, все будет меняться и дальше, это лишь дело времени: асинхронный рендеринг, кэширование, выход 17-й версии и много других, пока неизвестных вещей.
Поэтому желающие оставаться «в теме» должны знать, что происходит в сообществе.
Вы должны знать, как функционируют разные вещи и зачем они были разработаны. Изучайте, что за проблемы решаются сейчас и как именно облегчается разработка. Это в самом деле будет вам полезно.
Не бойтесь разбивать ваш код на меньшие кусочки
React основан на компонентах. Пользуясь этой концепцией, вы можете не бояться разбивать большие куски на кусочки поменьше. Несложный компонент порой может представлять собой 4-5 строк кода, и это просто отлично.
Вам нужно писать код так, чтобы новому человеку, подключившемуся к работе, не потребовалось тратить много времени на понимание того, как он устроен.
[code]// ну разве это не просто для понимания?
return (
[
<ChangeButton onClick={this.changeUserApprovalStatus} text="Let’s switch it!" />,
<UserInformation status={status}/>
]
);
[/code]
Не все ваши компоненты должны иметь сложную встроенную логику. Они могут быть просто визуальными. Если это улучшит читабельность кода и процесс тестирования, уменьшит запашок кода, то это будет победой для всей команды.
[code]import ErrorMessage from ‘./ErrorMessage’;
const NotFound = () => (
<ErrorMessage title="Oops! Page not found." message="The page you are looking for does not exist!" className="test_404-page" />
);[/code]
В приведенном выше примере свойства статичны. Так что у вас может быть чистый компонент, отвечающий лишь за уведомление об ошибке на сайте.
Если вам не по вкусу, когда у вас повсюду CSS-классы, я рекомендую применять стилизованные компоненты. Это может сильно повысить читабельность кода.
[code]const Number = styled.h1`
font-size: 36px;
line-height: 40px;
margin-right: 5px;
padding: 0px;
`;
//..
<Container>
<Number>{skipRatePre}</Number>
<InfoName>Skip Rate</InfoName>
</Container>[/code]
Если вы не хотите растить количество компонентов из опасения засорить папки файлами, подумайте еще раз о структуре своего кода. Я использую фрактальную структуру, и она прекрасна.
Не тормозите на основах – продвигайтесь вперед
Возможно, вы считаете, что для перехода к более продвинутым вещам вам не хватает понимания основ. Но порой не стоит слишком сильно беспокоиться об этом: принимайте вызов и доказывайте самому себе, что ошибались.
Когда вы беретесь за более сложные темы и толкаете себя вперед, у вас может появиться более глубокое понимание основ и их использования.
Вы можете изучить много разных тем:
- Составные компоненты
- Компоненты высшего порядка (старшие компоненты)
- Render Props
- Умные/глупые компоненты
- и другие (попробуйте профайлинг)
И когда вы изучите их и научитесь применять, вы почувствуете себя гораздо увереннее в работе с React.
[code]// похоже на волшебство?
// это не так сложно, просто попробуйте
render() {
const children = React.Children.map(this.props.children,
(child, index) => {
return React.cloneElement(child, {
onSelect: () => this.props.onTabSelect(index)
});
});
return children;
}[/code]
И не опасайтесь испытывать что-то новое в своей работе (до некоторого предела, конечно!). Ставьте эксперименты не только в собственных проектах.
Вас, естественно, будут спрашивать, что это вы сделали и зачем. Ваша задача – привести веские доводы в защиту своих решений.
Вашей целью должно быть решение существующей проблемы, облегчение дальнейшей разработки или просто чистка спагетти-кода. Даже если ваши предложения будут отклонены, вы завершите свой рабочий день, унося больше знаний, чем если бы просто сидели тихонечко.
Не нужно слишком все усложнять
В жизни, да и вообще во всем, нужно стремиться к балансу. Не стоит что-то переусложнять просто чтобы покрасоваться. Нужно быть практичным. Пишите код простой для понимания и при этом выполняющий свою функцию.
Если вам не нужен Redux, но вы хотите его использовать только потому что так делают все, – не стоит этого делать. У вас может быть свое мнение и не нужно стесняться отстаивать его, даже если на вас давят.
Вас может посетить идея, что, применяя новейшие технологии и выдавая на-гора сложный код, вы говорите миру, что вы уже не новичок. Что вы превращаетесь в мидла или даже сеньора. «Поглядите, как я могу!»
Честно говоря, в начале своей карьеры я сам таким грешил. Но постепенно вы поймете, что просто рабочий код, написанный без показухи, гораздо лучше:
- Над вашими проектами могут работать и ваши сотрудники. Вы не единственный ответственный за разработку/исправление/тестирование/<вставьте-сюда-любую-задачу>.
- Команда понимает, кто чем занят, и без долгого просиживания на планерках. Это сокращает время собраний.
- Когда ваш товарищ по команде идет в отпуск, вы можете заняться его задачами. И вам не придется корпеть над ними весь день, ведь вы сможете управиться за час.
Люди уважают тех, кто облегчает им жизнь. Таким образом, если вы желаете добиться уважения окружающих, – поднимайте планку, совершенствуйтесь и старайтесь писать код для команды, а не для себя лично.
Так вы станете прекрасным командным игроком.
Рефакторинг, рефакторинг и еще раз рефакторинг
Вы будете десятки раз менять свое мнение, а менеджер проекта — и того чаще. Окружающие будут критиковать вашу работу, а вы – их. В результате вам придется неоднократно переделывать свой код.
Однако не нужно волноваться, это нормальный учебный процесс. На ошибках учатся.
Чем чаще вы падаете, тем легче становится подниматься.
Главное, тестируйте свои программы. Дымовое, модульное, интеграционное тестирование, тесты с помощью снимков – не стесняйтесь их. Каждый сталкивался (или еще столкнется) с ситуацией, когда благодаря тестам удалось сэкономить время.
А если вы, как и многие другие, думаете, что тестирование это скорее потеря времени, попытайтесь посмотреть на это немного иначе:
- Вам не придется объяснять товарищам по команде, как все работает.
- Вам не придется объяснять им, почему все ломается.
- Вам не придется фиксить баги для вашего коллеги.
- Вам не придется фиксить баги, найденные через 3 недели.
- У вас будет время заняться тем, чем вы хотите.
Это весомые аргументы, подумайте над этим.
Если вы любите свое дело, то все у вас получится
В прошедшем году моей целью было совершенствовать свои знания React. Мне хотелось выступить с речью на эту тему, чтобы и другие насладились вместе со мной.
Я мог провести всю ночь за программированием или за просмотром выступлений других людей, и наслаждался при этом каждым мгновением.
Любопытно, что когда вы чего-то сильно хотите, каким-то образом все начинают вам помогать. И вот в прошлом месяце я впервые произнес речь на тему React перед 200 людьми.
За этот год я стал увереннее в работе с React. Я могу обсуждать какие-то продвинутые вещи и учить других тому, за что раньше боялся даже браться.
И сегодня воодушевление и удовольствие от работы остались теми же, что были раньше.
В связи с этим я бы каждому советовал спросить себя: «Наслаждаюсь ли я тем, чем занимаюсь?»
Если нет – продолжайте искать что-то особенное, о чем сможете говорить не переставая, что будете изучать по ночам и быть при этом счастливым.
Успех нельзя завоевать, его можно только достигнуть.
Именно этими словами я подбодрил бы себя перед длительным путешествием в мир React, если бы мог вернуться в прошлое.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
Очень важный момент упустил это товарищ, а именно статическую типизацию (TypeScript/Flow), которая обязательна в больших командных проектах (на самом деле в любых).