Начало работы с новой технологией может быть довольно проблематичным. Вы обычно обнаруживаете себя в море туториалов и статей с миллионами личных мнений. И каждый утверждает, что нашел «правильный и совершенный путь.»
Это оставляет нас в раздумьях, будет ли выбранное руководство пустой тратой времени или нет.
Перед тем, как углубиться, мы должны понять ключевые концепции технологии. Затем нам нужно развивать мышление, основанное на технологии. Если мы начинаем изучать React, мы должны начать думать «по-реактовски». Только после этого мы сможем соединить разные подходы в один.
В этой статье мы рассмотрим кое-какие уроки, которые я вынес из собственного опыта c React. Мы перенесемся в мои дни на работе, ночи над личными проектами и даже выступление на местном мероприятии JavaScript.
Итак давайте начнем!
React развивается, вы должны быть в курсе
Если вы помните первый анонс версии 16.3.0, вы вспомните, как все были взволнованы.
Вот изменения и улучшения, которые мы получили:
- Официальное Context API
- createRef API
- forwardRef API
- StrictMode
- Изменения в жизненном цикле компонента
Команда React Core и все контрибьюторы делают большую работу, пытаясь улучшить технологию, которую мы все обожаем. И в версии 16.4.0 мы получили Pointer Events.
Дальнейшие изменения безусловно будут, и это только вопрос времени: асинхронный рендеринг, кэширование, версия 17.0.0 и многие другие еще не известные.
Так что если вы хотите быть на высоте, вы должны быть в курсе того, что происходит в сообществе.
Знать, как те или иные инструменты работают и почему они разрабатываются. Узнать, какие проблемы решаются и как упрощается разработка. Это обязательно поможет вам.
Не бойтесь разбивать код на маленькие части
React основан на компонентах. Таким образом, вы должны использовать эту концепцию и не бояться разбивать большие части на более мелкие.
Иногда простой компонент может состоять из 4-5 строчек кода, и в некоторых случаях это абсолютно нормально.
Пишите код так, чтобы человеку, незнакомому с ним, не понадобилось несколько дней, чтобы понять, как все работает.
Вам не нужно делать компоненты так, чтобы в них содержалась вся сложная логика. Они могут быть только для представления. Если это улучшает читаемость, тестирование кода и упрощает дальнейшую работу с кодом, то это выигрыш для всех в команде.
В примере выше свойства статичны. То есть мы можем использовать чистый компонент, который отвечает только за отображение сообщения об ошибке Not Found и ни за что больше.
Также если вам не нравится использовать CSS классы с помощью переменных className повсюду, я бы рекомендовал делать компоненты для стилизации. Это может сильно улучшить читаемость.
Если вы боитесь создавать больше компонентов, чтобы не перегружать папки с файлами, пересмотрите структуру вашего кода. Я использовал фрактальную структуру (fractal structure), и она замечательная.
Не застревайте на основах — продвигайтесь
Вы можете иногда думать, что недостаточно знаете для того, чтобы переходить к продвинутому материалу. Но зачастую вы не должны сильно об этом беспокоиться — примите вызов и докажите себе, что были неправы.
Если будете заставлять себя разбирать сложные темы, то сможете лучше понять основы и то, как они применяются в более объемных концепциях.
Есть много паттернов, которые вам нужно изучить:
- Композиция компонентов (Compound Components)
- Компоненты высшего порядка (High Order Components)
- Render Props
- Умные/глупые компоненты (Smart/Dumb Components)
- многие другие (попробуйте анализ производительности (Profiling))
Изучите их все и вы узнаете почему и где они применяются. Вам станет более комфортно работать с Реактом.
Также не бойтесь пробовать что-то новое в работе — в определенных рамках, конечно. Экспериментируйте не только над личными проектами.
Люди будут задавать вопросы, и это нормально. Ваша задача — отстаивать свою работу и решения сильными аргументами.
Ваша цель должна состоять в том, чтобы решить существующую проблему, облегчить дальнейшее развитие проекта или просто убрать спагетти-код. Даже если ваши предложения будут отклонены, вы вернетесь домой, зная больше, чем сидя молча.
Не переусложняйте вещи
Это может звучать как контраргумент, но это другое. В жизни, и везде, мы должны иметь баланс. Мы не должны переусложнять код, чтобы покрасоваться. Мы должны быть практичными. Пишите код, который легко понять и который выполняет свое предназначение.
Если Вам не нужен Redux, но вы хотите использовать его, потому что все используют, не зная его истинную цель, не делайте этого. Имейте свое мнение и не бойтесь отстоять его, если другие подталкивают вас.
Иногда вы возможно думаете, что если применяете новейшие технологии и пишете сложный код, то вы заявляете миру:
«Я не джуниор, я становлюсь миддлом/синьором. Посмотрите, что я могу!»
Честно говоря, это было мое мышление в начале моего пути разработчика. Но со временем вы понимаете, что с кодом, который был написан без выпендривания или потому что «он работает», легче жить. А именно:
- Коллеги могут работать над вашими проектами, и вы не единственный, кто отвечает за разработку/дебаггинг/тестирование/<вставьте задачу>.
- Команда может понимать, что делают другие без участия в длительных совещаниях. Пары минут достаточно для обсуждения.
- Когда ваш коллега уйдет в двухнедельный отпуск, вы сможете взять его задачу. и вам не нужно будет над ней работать 8 часов, потому что ее можно сделать за час.
Люди уважают тех людей, которые делают жизнь других легче. Поэтому если ваша цель — заслужить уважение, повыситься и продвинуться, стремитесь писать код для команды, а не для себя.
Вы станете всеми любимым членом команды.
Рефакторьте, рефакторьте и рефакторьте — это нормально
Вы будете менять свое мнение десятки раз, а руководитель проекта будет менять его еще чаще. Другие будут критиковать вашу работу, и вы будете критиковать ее. В результате вам придется менять код много-много раз.
Но не переживайте, это естественный процесс обучения. Без провалов и ошибок мы не можем развиваться.
Чем больше мы падаем, тем легче каждый раз нам подниматься.
Но есть совет: убедитесь, что тестируете программу, над которой работаете.
Каждый сталкивался или столкнется со сценарием, когда тест мог бы сэкономить драгоценное время.
А если вы, как и многие люди, думаете, что это пустая трата времени, просто попробуйте подумать немного иначе.
- Вам не придется сидеть со своим коллегой, объясняя, как все работает.
- Вам не придется сидеть со своим коллегой, объясняя, почему все сломалось.
- Вам не придется исправлять ошибки для вашего коллеги.
- Вам не придется исправлять ошибки, которые были обнаружены через 3 недели.
- У вас будет время делать то, что вы хотите.
И это довольно большие преимущества.
Если вы любите это, все получится
Целью моего прошлого года было улучшить свои навыки в React. Я хотел поговорить об этом. Я хотел, чтобы другие наслаждались этим со мной.
Я мог сидеть всю ночь, наблюдая за различными выступлениями и наслаждаться каждой минутой (имеется в виду — обучения, прим. переводчика).
Дело в том, что если ты чего-то хочешь, почему-то все начинают тебе помогать. И в прошлом месяце я впервые выступил с докладом по React перед толпой из 200 человек.
В течение этого года я стал сильнее и мне стало комфортно с React — с различными моделями, парадигмами и внутренним устройством. Я могу участвовать в дискуссии на продвинутые темы и научить других темам, которых раньше боялся коснуться.
И сегодня я все еще чувствую то же волнение и наслаждение, что и год назад.
Поэтому я рекомендую всем спросить себя: «Вам нравится то, что вы делаете?»
Если нет, продолжайте искать ту область, о которой вы можете говорить часами, учить целыми ночами и быть счастливым.
Потому что мы должны найти то, что ближе нашему сердцу. Успех не может быть принудительным, он должен быть достигнут.
Если бы я мог вернуться на год назад, это то, что я бы сказал себе, чтобы подготовиться перед большим путешествием вперед.
Спасибо за чтение!
Оригинал — Tomas Eglinskas
Перевод — Юлия Аюбова
