Нерушимая связь

Из всех статей, которые я прочитал, в которых сравниваются и противопоставляются различия между VueJS и React, есть один существенный недостаток, который я не видел подробно. Потерпи меня, пока я на цыпочках разбираюсь в деталях.

Если вы не знакомы с типичными различиями, которые чаще всего упоминаются между Vue и React, они включают такие вещи, как:

  • скорость рендеринга (преимущество: Vue [до React Fiber])
  • кривая обучения / простота использования (преимущество: Vue)
  • время установки нового приложения (преимущество: Vue)
  • основной набор функций (равно [ReactNative? Weex.])
  • пользовательские директивы (преимущество: Vue)
  • условные элементы / рендеринг (преимущество: Vue)
  • гибкость (преимущество: Vue)
  • строго JavaScript (преимущество: React)

(Как вы можете ясно видеть, этот автор в значительной степени беспристрастен.)

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

Устаревшие системы

Представьте, например, что вы столкнулись с большой, неуклюжей формой ввода данных с большим количеством полей и логики в устаревшей системе, и вам была поставлена ​​задача модернизировать ее с помощью новой причудливой интерфейсной среды. Эта форма может быть структурирована следующим образом:

Если бы вы подошли к этому проекту с VueJS в качестве предпочтительного внешнего фреймворка, вы могли бы завершить работу с некоторыми настройками разметки и новым файлом .js. Например:

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

С React вы не сможете использовать любую устаревшую реализацию как есть и на месте. Вместо этого вам нужно будет вставить всю разметку в новые компоненты React и соответствующим образом провести рефакторинг.

Более того, даже если вы переписываете полностью новые компоненты React, вы не сможете просто загрузить новый код на страницу. Вместо этого вам придется дополнить весь процесс разработки, чтобы включить в рабочий процесс дополнительные шаги, связанные с бабелизацией / транспиляцией и развертыванием вашего нового кода React. Это подводит меня к сути этой статьи, которая является связанной, но более широкой проблемой.

Тесная связь

Одна из трудностей, лежащих в основе React, которую я до сих пор не назвал по имени, - это то, как написана его разметка: JSX. Одно из наиболее известных и значительных различий между Vue и React заключается в том, что все в React строго основано на JavaScript, однако Vue достаточно гибок, чтобы компоненты были основаны на реальных элементах DOM, текстовой разметке HTML. или даже JSX (который, как мне кажется, поддерживается, чтобы побудить робких разработчиков React перейти на яркую сторону).

Есть опытные разработчики, которые предпочитают React, потому что им нравится, что он полностью основан на JS. Я слышал от таких разработчиков:

«Кажется более естественным делать все в React, потому что это полностью JavaScript, но Vue использует атрибуты HTML для управления DOM, что неестественно».

Ну ладно, каждому свое… по крайней мере, что касается мнения. Но объективно это означает, что вы должны создать всю разметку DOM, используя специальную грамматику, изобретенную Facebook (которая, кстати, кажется очень не Естественно для этого автора). И поскольку он написан нестандартным, нестандартным способом, ваш код React не может быть напрямую выполнен на странице; сначала он должен быть переведен на актуальный естественный JavaScript.

Чтобы проиллюстрировать это немного дальше, рассмотрим следующую разметку:

<div id="some-block">
  <h1>arbitrary content</h1>
</div>
<script type="text/x-template" id="my-template">
  <p>Lorem ipsum dolor sit foobar</p>
</script>

Вы можете создать экземпляры компонентов Vue, прикрепив их к фактическому элементу в DOM:

new Vue({ el: '#some-block' })

Или используя строку разметки (будь то шаблон <script> на странице, строка в JS, данные, полученные через Ajax, и т. Д.):

Vue.component('my-component', { template: '#my-template' })

Это замечательно, если вы используете Vue, хотя, поскольку вы не можете ни писать простой HTML в React, ни подключать компонент React к существующим элементам DOM, ваши руки связаны. Под этим я подразумеваю, что вы не можете вместо точки JSX реагировать на существующий идентификатор в DOM и неявно анализировать это поддерево как JSX.

Чтобы выполнить эквивалент в React, вы не можете просто сослаться на существующий DOM или внешний HTML. Вместо этого вам нужно будет определить новый JSX внутри вашего компонента. Например (при условии, что мы собираемся создать компонент с отслеживанием состояния):

class MyComponent extends Component {
  constructor(props) {
    super(props)
    // ... set state ...
  }
  render() {
    // don't let its appearance fool you - this isn't HTML
    return (
      <p>Lorem ipsum dolor sit foobar</p>
    )
  }
}
// ...define props and their defaults...

Поскольку React в этом смысле настолько жесткий и негибкий, это означает:

В компонентах React вы не можете изменить разметку без перекомпиляции.

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

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

Если простая разметка уровня представления запутана внутри низкоуровневого программирования, это означает, что не только переход от устаревшего кода к React потребует переписывания вместо рефакторинга, но и переход в будущем из React на другую платформу, скорее всего, потребует повторной перезаписи с нуля, а не просто рефакторинга. Это не обязательно проблема сегодня, но в какой-то момент Future You & I, вероятно, столкнемся с этой загадкой с появлением фреймворков следующего поколения next. Я считаю, что хорошим принципом является предпочтение реализации, которую не только легко реализовать на начальном этапе, но и которая позволит вам легко уйти от нее позже.

Заключение

Цель этой статьи не в том, чтобы громить React, чтобы похвалить Vue, и не в том, чтобы отговорить всех от использования React в пользу Vue. Как гласит мантра: вы всегда должны использовать правильный инструмент для работы, каким бы он ни был. Я только надеюсь пролить свет на то, что, по моему мнению, может быть потенциально важным фактором для компании или команды разработчиков при принятии решения о том, в какой интерфейсной среде они могут быть заблокированы в обозримом будущем. (Кто знает? Может быть, это часть плана - заставить всех полагаться на React и, по доверенности, на Facebook. Это сработало для Microsoft.)

Тем временем…

Хакерский полдень - это то, с чего хакеры начинают свои дни. Мы часть семьи @AMI. Сейчас мы принимаем заявки и рады обсудить рекламные и спонсорские возможности.

Если вам понравился этот рассказ, мы рекомендуем прочитать наши Последние технические истории и Современные технические истории. До следующего раза не воспринимайте реалии мира как должное!