Начальное состояние

Проработав с Vue большую часть последних 3 лет, я очень привык к синтаксису и библиотекам Vue, и мне стало очень комфортно с фреймворком. Vue было легко подобрать в основном по двум причинам:

  1. Четко сегментированная структура компонентов — HTML-шаблон, JS и CSS.
  2. Интуитивно понятные параметры в сегменте JS — компоненты, реквизиты, данные, вычисляемые, методы, часы и хуки жизненного цикла.

Возможно, любой человек, имеющий опыт работы с HTML/CSS и изучающий хорошо написанный компонент Vue, может составить хорошее представление о том, что он делает и как работает, не обращаясь к документации. Относительный новичок в программировании также найдет очень полезными интуитивно понятные названия опций.

Мутация

Перенесемся на год назад, мои знания о React были ограничены несколькими статьями, которые я читал, сравнивая Vue и React и какие из них использовать (их много, и в основном это не сразу заметно, если вы никогда не использовали оба) и немного баловались с созданием простых компонентов. в React, следуя руководству по началу работы. Все казалось довольно простым. Я имею в виду, насколько разными могут быть эти две структуры, верно?

Затем появилась возможность по-настоящему освоить React, когда я сменил работу. И я был ошеломлен.

Эта статья призвана помочь другим (с опытом работы с Vue и без него) понять функциональные компоненты React и быстрее освоить концепции React. Он не пытается сравнивать Vue и React как конкурирующие фреймворки, и его намерение не состоит в том, чтобы ранжировать один над другим.

5 вещей, с которыми я боролся

1. Структура кода

В Vue каждый компонент состоит из трех сегментов:

  • <template> (HTML/JSX),
  • <script> (JS структурирован в рамках опций с интуитивно понятными названиями),
  • <style> (CSS).

Он очень похож на макет типичной HTML-страницы, хотя и со стилем в «нижнем колонтитуле», а не в «шапке».

В функциональных компонентах React основным базовым ключом является то, что код компонента выполняется последовательно сверху вниз, как типичный скрипт JS, и возвращает значение, обычно HTML/JSX. Исходя из Vue, структура выглядела так:

  • Одна большая каша (JS — неструктурированное вкрапление хуков и методов),
  • возврат (HTML/JSX)

На первый взгляд, без фиксированной структуры сегмента JS пытаться понять код, написанный другими, было непросто, особенно если не было комментариев. Не помогло то, что встроенные хуки названы так технически (useEffect, useMemo, useCallback) и что без обращения к документации невозможно понять, для чего нужен второй аргумент в вышеупомянутых хуках. Таким образом, хотя эти хуки более гибкие и, следовательно, могут использоваться повторно, чем их аналоги Vue (watch - useEffect, computed - useMemo и useCallback, mounted - хуки с пустым вторым аргументом), они также гораздо менее интерпретируемы.

Тем не менее, когда я начал писать свои собственные компоненты, я начал понимать, что, хотя фиксированной структуры не было, были определенные правила (например, правила хуков), которые заставляли мой код соответствовать неявно определенной структуре. Во всех своих компонентах я обычно определял все состояния, используемые внутри компонента, и размещал весь код настройки чуть ниже. После этого я обнаружил, что структурирую код в блоки логических задач, очень похоже на то, как я структурировал свою опцию methods в Vue.

Затем я понял, что то, что для моего непосвященного «я» выглядело как один большой беспорядок, на самом деле имело общую структуру для всех проектов — мне просто нужно было более глубоко понять функциональность и варианты использования хуков, прежде чем я мог расшифровать структуру компонента React. И это не крутая кривая обучения, если вы уже понимаете основные вычислительные концепции (побочные эффекты, запоминание, обратные вызовы).

Для тех, кто пришел из Vue, вот краткий глоссарий, который поможет понять, как определенные хуки переводятся в концепции Vue.

Функция React HookVue optionuseStatedatauseEffect(, [x])watchuseCallback(, [x])computeduseMemo(, [x])computeduseEffect(, []), useCallback(, []), useMemo(, [])mountedreturn вызывается внутри useEffect(... return function(), [])unmounted

А для тех, у кого нет опыта работы с Vue, вот краткое изложение того, что я узнал о структуре кода в функциональных компонентах React.

  • Некоторые методы, константы и стили могут быть определены за пределами компонента (обычно в начале файла). Это оптимизация, чтобы указанные объекты не создавались заново при каждом рендеринге.
  • Компоненты обычно начинаются с извлечения свойств, определения состояний и импорта повторно используемых методов/хелперов. Это очень похоже на то, как структурированы файлы JS.
  • Далее обычно следуют методы настройки: настройка состояний при монтировании, вычисление производных значений, выборка данных.
  • Вся остальная логика, используемая в компоненте, надеюсь, организована по логическим соображениям.
  • Если вам интересно, где появляется CSS, React не диктует, как использовать CSS. Вы можете импортировать файлы CSS, определять встроенные стили или использовать библиотеку CSS-in-JS.

2. Методы жизненного цикла

Одной из ключевых концепций Vue, которую я действительно ценю, является четкое определение и документирование жизненного цикла компонента. React тоже пытается задокументировать это, но не в такой степени, как Vue, а API работает только для компонентов класса. С переходом React на функциональные компоненты методы жизненного цикла уже не так легко доступны.

Когда я начал работать с React, одной из первых концепций, которые я хотел понять, был жизненный цикл компонента React. Привыкнув к хукам жизненного цикла Vue, я искал что-то подобное в функциональных компонентах React, но для этого нет документации в разделе «Состояние и жизненный цикл» официальных руководств React. И даже для компонентов класса React не делает весь жизненный цикл доступным, как это делает Vue.

Однако в Vue методы жизненного цикла, которые я чаще всего использую, монтируются и размонтируются. Итак, я действительно искал аналог в функциональных компонентах React. При дальнейшем гуглении я обнаружил, что хук useEffect может работать так же, как смонтированные/размонтированные хуки в Vue. Хотя это было не так интуитивно понятно, это был просто вопрос адаптации к React API. По крайней мере, у меня было решение для моих методов установки и демонтажа.

Короче говоря, здесь я узнал, что в функциональных компонентах React этап установки (обычно создаваемый/монтируемый в Vue) может быть записан с помощью useEffect(, []), а этап демонтажа (размонтированный во Vue) может быть записан с помощью useEffect. (… функция возврата(), []). Хотя в React нет доступа к другим методам жизненного цикла, они, вероятно, не требуются достаточно часто, чтобы доставлять большие неудобства.

3. Двусторонняя привязка против односторонней привязки

В Vue директива v-model позволяет выполнять двустороннюю привязку элементов ввода. С чисто ленивой (возможно, также ремонтопригодной) точки зрения это экономит много стандартного кода. Хотя я не хочу вступать в дискуссию о том, что лучше двусторонняя или односторонняя привязка, меня определенно раздражала необходимость писать шаблонные методы для обновления состояния при переключении на React. Это усугубляется тем фактом, что правильное выполнение React означало не изменение состояний, а создание копий и перенастройку состояний. Это означало, что код для форм в React был намного длиннее, чем аналогичный в Vue.

Для тех, кто не знает контекста, одним из основных аспектов React является односторонняя привязка данных, что вкратце означает, что данные передаются только в одном направлении. Это позволяет React более эффективно определять, изменилось ли состояние и что вызвало изменение.

В сложных компонентах Vue вы иногда сталкиваетесь с ситуациями, когда DOM не обновляется, несмотря на обновление наблюдаемого объекта. Редко, но бывает и надоедает отлаживать. Однако односторонняя привязка данных в React устраняет такие проблемы, поскольку вы запускаете обновление DOM вручную каждый раз, когда вызываете setState. Недостатком этого является то, что вам нужно написать код для запуска повторного рендеринга (setState), чего вам не нужно делать при использовании Vue.

По правде говоря, это было в основном просто раздражением, когда я только начал работать с React. С тех пор я создал повторно используемые компоненты и больше не пишу шаблоны для форм. На самом деле с помощью FormBlob я могу создать любую нужную мне форму за 2 минуты.

4. Ограниченный стиль (CSS)

Стилизация с заданной областью действия в Vue очень проста. Если вы знакомы с HTML/CSS, все происходит очень естественно — определите класс для вашего HTML-элемента, установите стили CSS для этого класса в сегменте <style scoped>.

Стили с заданной областью полезны для обеспечения того, чтобы стили применялись только внутри компонента, в котором они определены. Это позволяет нам повторно использовать имена классов в нескольких компонентах, не беспокоясь о том, что стили, определенные в другом месте, будут мешать. Это особенно полезно для создания библиотек компонентов, предназначенных для использования в нескольких проектах.

В React нет заранее определенных рекомендаций по применению CSS. Вы можете импортировать файлы CSS, использовать встроенные стили или использовать библиотеки CSS-in-JS. Некоторые библиотеки CSS-in-JS, такие как jss или эмоция, стали очень популярными и используются во многих проектах React. Однако, как и в случае с любой сторонней библиотекой, всегда есть кривая обучения, особенно при определении повторно используемых стилей.

Прежде чем меня будут ругать за то, что я слишком избалован, помните, что это мой опыт перехода с Vue на React. Во Vue мне не нужно было заново изучать какие-либо специфичные для Vue библиотеки стилей, и я мог достичь стиля с ограниченной областью действия с повторно используемыми именами классов из коробки, используя ванильный CSS. В React процесс достижения аналогичного результата, возможно, более утомительный, будь то написание собственного файла CSS или использование сторонних библиотек.

5. Справочные ресурсы и библиотеки

Один из аргументов в пользу React всегда заключается в том, что React, будучи более популярным фреймворком, имеет более глубокие онлайн-ресурсы и поддержку, к которым вы можете подключиться. По моему опыту, только начав работать с React после запуска функциональных компонентов, это не так.

React, который так долго существует с таким количеством версий (сейчас это v17), имеет большой ресурс устаревших решений и устаревших библиотек. Я считаю, что гораздо проще найти решения и соответствующие библиотеки для Vue (сейчас только v3), чем для React. С тех пор, как я начал работать с React, я обнаружил, что трачу значительно больше времени на гугление, чтобы найти решение, отвечающее моим потребностям, чем когда я работал с Vue. С личной точки зрения, это то, с чем я боролся, когда начинал в React. Большое количество решений, на которые я натыкаюсь, просто не будут работать, и потребуется больше времени, чтобы найти то, что работает. Но это может быть связано с моими неадекватными навыками гугления!

Заключение

Я использовал и Vue, и React для создания сложных приложений, и, честно говоря, теперь я лучше знаком с React, поскольку использовал его изо дня в день в течение прошлого года. Если бы мне нужно было начать новый проект сейчас, я бы сделал это с React просто потому, что я мог бы создать готовое приложение намного быстрее в React, чем в Vue прямо сейчас. С тех пор мне стало намного удобнее работать с React и его особенностями, и я не отдаю особого предпочтения ни Vue, ни React в качестве фреймворка.

Эта статья — личный анекдот и не предназначена для объективного сравнения Vue и React. Моя цель здесь — поделиться тем, чему я научился при переходе с Vue на React, и, надеюсь, помочь другим, кто делает то же самое или хочет изучить React. Я приветствую любые мнения и опыты, противоречащие тому, что я испытал, и я не собираюсь делать какие-либо огульные заявления или утверждения (даже если в рамках статьи это звучит именно так). Я изучаю программирование и всегда буду им, и рад учиться у кого угодно.

Ваше здоровье!