Сравнение React и Vue всегда было темой, которая является более спорной и противоречивой.Возможно, каждый интерфейс в большей или меньшей степени участвовал в этих дебатах, но ценный результат, полученный в этих огромных дебатах, всегда был скудным. Я не намерен вызывать здесь еще одну ссору, но, основываясь на собственном опыте, надеюсь максимально объективно объяснить некоторые различия, преимущества и недостатки двух фреймворков. На самом деле практически бессмысленно сравнивать два фреймворка в соответствии с документацией и некоторыми демонстрациями без фактического использования двух фреймворков в производственной среде. В прошлом году я практически только использовал vue в своей работе, т.к. технологический стек последнего отдела компании был только vue, хотя я тоже научился реагировать и сделал несколько демок по документации, но когда очень захотелось узнать react и vue на в то время в чем конкретная разница между ними, а затем найдите несколько статей о реакции, чтобы прочитать, потому что нет никакого практического и систематического исследования реакции, трудно действительно понять реальную разницу между ними. Теперь, после того, как я фактически написал React около 3 месяцев, самое большое открытие состоит в том, что на самом деле есть много различий.Если вы будете писать и писать, он будет медленно всплывать на воду, поэтому рекомендуется, чтобы было больше студентов с разрозненными технологиями. стопки в отделе.Попробовать,лучший способ разобраться в проблеме-попробовать ответить на нее самому.
Нижеследующее представляет собой только личные мнения и не гарантирует, что все мнения верны.
diff, патч и обновление
react:В react, если состояние компонента изменится, react повторно отрендерит этот компонент и все дочерние компоненты этого компонента, но повторный рендеринг не означает, что все предыдущие результаты рендеринга будут отброшены, и react все равно будет сравнивать через diff посередине Две виртуальные модели DOM окончательно запатентованы в настоящую модель DOM. Даже в этом случае, если дерево компонентов слишком велико, при сравнении все равно будут возникать некоторые накладные расходы, поскольку процесс сравнения по-прежнему сравнивает все дерево компонентов, корнем которого является этот компонент. Решение, предоставленное реагированием на нас,shouldComponentUpdate, результат, возвращаемый этой функцией, используется для определения необходимости выполнения следующих изменений, исправлений и обновлений. В реальном процессе разработки мы часто используемpureComponentчтобы помочь нам сделать это логическое суждение, но следует отметить, чтоpureComponentизshouldComponentUpdateЭто только поверхностное сравнение, если предположить, что тип сравнения - объект, если меняются только свойства объекта, но его ссылка не меняется, тоshouldComponentUpdateможно подумать, что между ними ничего не изменилось.
vue:Адаптивное использование VueObject.definePropertyapi, и из-за реализации сбора зависимостей в геттере он не будет сравнивать все дерево компонентов, как реагировать, а будет более мелкозернистым, чтобы обновлять компоненты с измененными состояниями, и в то же времяdefinePropertyнет такой вещи, какshouldComponentUpdateСравните упомянутый вопрос в .
В сравнении:Обновление vue более детализировано, чем обновление реакции, и требует меньше человеческого внимания, хотя реакция может пройти.shouldComponentUpdateОднако для достижения того же эффекта, если иерархическая структура состояния относительно глубокая, будет трудоемче вручную оптимизировать эту часть кода, поэтому в реакции нам нужно максимально обеспечить плоскостность всей структуры. можно позволитьpureComponentПомогите нам оптимизировать это автоматически.
Как изменяются данные о состоянии
react: поскольку и react, и redux продвигают функциональное программирование, аналогичные изменения состояния аналогичны следующему коду.
state = {
obj: {a: 1, b: 2},
arr: [1, 2, 3],
}
// 修改obj.b
modifyObj = () => {
this.setState({
obj: {
...this.state.obj,
b: 3,
}
})
}
// 修改arr
modifyArr = () => {
this.setState({
arr: [...this.state.arr, 4],
})
}
На самом деле можно напрямую изменять объекты или массивы, например, напрямую изменятьobj.b = 3,ПотомsetState({ obj }), в некоторых случаях это не вызовет никаких ошибок, но, во-первых, поскольку react и redux сами по себе уважают функциональное программирование, официально не рекомендуется напрямую изменять объекты или массивы. Во-вторых, помните, что мы сказали вышеpureComponent, потому чтоshouldComponentUpdateЭто поверхностное сравнение, если объект или массив изменены напрямую, компонент не будет обновлен.
vue:Vue относительно просто модифицирует данные состояния.Для объектов мы можем напрямуюthis.obj.b = 3Вот и все.В это время сеттер, установленный во время начального рендеринга, будет запущен, а затем будет вызван метод уведомления, чтобы уведомить всех наблюдателей о выполнении обновления. А вот для модификации массива vue не так лаконичен, хотя мы все равно можем модифицировать массив через push, unshift и другие методы, но аналогичноarr[index] = someValЭтот метод не будет работать. В настоящее время либо используйте метод соединения, либо сопоставьте новый массив и переназначьте его способом, подобным реакции. В последнее время постепенно всплывает vue3.На недавней vueConf было объявлено, что vue3 принимает схему прокси, поэтому можно использовать смену массива в vue3.arr[index]вверх.
В сравнении:В случае данных как объекта кодовый метод vue проще и удобнее, а в случае массива особой разницы между vue и react нет, и нам все равно нужно использовать такие функции как map и filter в довольно многих случаях. Но обратите внимание, что простота и удобство vue не означает, что он лучше сам по себе Причина, по которой react и redux выступают за то, чтобы всегда заменять старые значения новыми значениями, заключается в том, что его легче отлаживать и некоторые функции путешествия во времени, но для vue это не конфликтует. Если хотите, вы также можете написать свой код vue таким образом. Кроме того, хотя кажетсяObject.definePropertyЭтот API очень помогает Vue, но не без побочных эффектов.Когда данные о состоянии огромны, поскольку этому API необходимо рекурсивно отслеживать данные о состоянии, начальное потребление Vue может быть больше, а соответствующее время белого экрана дольше, чем реагировать, и эта проблема также будет решена в vue3, потому что мониторинг на основе прокси похож на ленивый.
О логическом мультиплексировании
react:Логическое повторное использование - очень интересный кусок контента. Я очень хочу вздохнуть о качественных решениях, предоставленных сообществом реакции и сообществом, от миксинов до высокоуровневых компонентов до renderProps. Здесь мы в основном берем renderProps в качестве примера. это позже. Так называемый комплекс логики заключается в повторном использовании некоторой общей логики для компонентов, которым эта логика нужна.Давайте рассмотрим случай, предоставленный официальной документацией по реакции.
Это компонент, который отображает положение мыши в реальном времени.Для этого компонента основная логика заключается в обработке событий мыши, но эта часть просто место, которое трудно переиспользовать.Предположим, мы хотим отрендерить кота в другом В то же время его положение определяется положением мыши, поэтому нам в основном приходится заново писать код этой части событий и состояний мыши, чтобы увидеть, как renderProps решает проблему.
Первый раз, когда вижу такой код, очень хочется немного вздохнуть о том, как, блядь, получилось, абстрагируя компонент Mouse, отвечающий за поведение, и затем передавая состояние в качестве параметра в функцию внешнего возвращаемого компонента, это действительно потрясающе. Кстати, не обязательно использовать реквизит рендера, например, в этом примере мы можем написать его в виде кода.
<Mouse>
{
mouse => <Cat mouse={mouse} />
}
</Mouse>
// Mouse组件
<div onMouseMove={this.handleMouse}>{this.props.children(this.state)}</div>
Соответственно мы можем сделать много такой инкапсуляции, типа переключения модального окна, типа инкапсуляции onChange и setState of Input, Select и других контролов, просто для примера
<Container>
{
(value, changeValue) => <Input value={value} onChange={changeValue} />
}
</Container>
Представьте себе обычный сценарий, 4 входа плюс кнопку поиска кнопки, а затем отобразите искомые данные в таблице. Использование этого пакета может сэкономить много шаблонного кода.
vue:Давайте посмотрим непосредственно на то, как vue реализует описанную выше логику повторного использования мыши.
// 指令
Vue.directive('mouse', {
binding: function (el, binding) {
function mouseMove(e) {
binding.value.x = e.clientX;
binding.value.y = e.clientY;
}
el.__mouseMove = mouseMove;
el.addEventListener('mousemove', mouseMove);
},
unbinding: function (el) {
el.removeEventListener('mousemove', el.__mouseMove);
}
})
// 组件中
<template>
<div v-model="data">
{{ data.x }}, {{ data.y }}
</div>
</template>
Непосредственно регистрируя инструкцию v-mouse, мы можем повторно использовать эту логику в любом компоненте.На самом деле, я лично считаю, что реализация vue лучше с точки зрения этих двух частей кода.Декларативная инструкция v-mouse очень Ясен и элегантен, но мы должны понимать, что это всего лишь очень простая часть логики.Если логика более сложная, нет сомнений, что гибкость и ремонтопригодность реакции намного лучше, чем способ инструкций.
В сравнении:Хотя renderProps реакции немного громоздкий, он определенно лучше, чем инструкции vue с точки зрения гибкости и удобства обслуживания. Тем не менее, в некоторых простых сценариях инструкции vue действительно очень удобны, например, наиболее часто используемая встроенная v-модель, все же вспомните сценарий, который мы описали ранее, несколько входов плюс одна кнопка, vue соответствует только 4v-model="value".
поток данных
На самом деле разница между ними не в этой части, но многие люди подсознательно реагируют на двустороннюю привязку данных, когда видят v-модель. Во многих ответах, сравнивающих vue и react, по-прежнему говорится, что, поскольку vue является двусторонней привязкой данных, данные легко запутаться и их трудно поддерживать в больших проектах, что действительно забавно. На самом деле, поток данных vue и react между компонентами является односторонним от родителя к дочернему, а дочерним компонентам не разрешено изменять реквизиты, между ними нет никакой разницы, а v-модель, похожая на ввод, является просто логическим Таким образом, или декларативный синтаксический сахар, то же самое использование v-модели для компонентов по-прежнему является синтаксическим сахаром, но поток данных по-прежнему является четким односторонним потоком.
компоненты более высокого порядка
react:Компоненты более высокого порядка — еще одна форма логики мультиплексирования. Так называемые компоненты более высокого порядка на самом деле такие же, как и функции более высокого порядка, за исключением того, что функция получает компонент, а затем возвращает компонент. Чтобы привести общий пример, предположим, что у нас есть интерфейс для получения дерева организации компании.Это дерево организации используется во многих сценариях, и мы можем извлечь общий компонент высокого порядка.
function HOC(wrapperComponent) {
return class getOrgTree extends React.Component {
state = { orgTree: [] }
componentDidMount() {
fetch('xxxxxxx').then(orgTree => this.setState({ orgTree }))
}
render() {
return <wrapperComponent orgTree={this.state.orgTree} {...this.props} />
}
}
}
С помощью этой функции мы можем передать любой из наших собственных компонентов в функцию, чтобы иметь реквизиты orgTree.Кроме того, мы также можем уменьшить или увеличить различные реквизиты и другие расширяемые операции с помощью компонентов более высокого порядка.
vue:Подобные операции vue могут быть достигнуты только с помощью миксинов (легко загрязнять и нелегко отлаживать), и еще сложнее расширить компоненты, использующие миксины. Разница между ними заключается в том, что компоненты реакции кажутся нося слой брони Преобразованные компоненты vue просто берут вещи и кладут их в свои карманы и, по сути, сами по себе.
const myMixin = {
created: function () {
fetch('xxxxx').then(orgTree => this.orgTree = orgTree)
},
}
В сравнении:На этом этапе функций более высокого порядка React по-прежнему достигает высокой степени масштабируемости и гибкости за счет объектно-ориентированных методов.Vue почти не имеет места для функций более высокого порядка, потому что Vue фактически ориентирован на конфигурацию (опции), хотя мы можем использовать Функция рендеринга может написать что-то похожее на высокоуровневый компонент, но читабельность кода, написанного первым рендером, все еще очень плохая (хотя кажется, что для написания jsx можно использовать и babel, но почему бы и нет использовать реагировать напрямую), второй почти отклоняется от режима разработки Vue, поэтому фактически с точки зрения применения некоторых режимов и логического повторного использования реакция лидирует. Но хорошая новость заключается в том, что компоненты vue3 также являются классами, которые могут помочь vue улучшить эту короткую доску.
Поддержка TypeScript
В сравнении:Хотя vue2 поддерживает его, он не очень хорош в использовании, многие уровни отстают от реакции. Это все еще проблема, решаемая vue3.
Сообщество и окружающая экология
В сравнении:На самом деле, я думаю, что большая часть разрыва между React и Vue заключается в сообществе и некоторой экологии.Вклад React в сообщество действительно довольно активен, различные решения, различные зрелые компоненты (не только библиотека пользовательского интерфейса), условно говоря, vue намного спокойнее, да и качество многих компонентов недостаточно высокое.Это не та проблема, которую может решить vue3.Единственное, на что можно положиться, это время.
Суммировать
Заключение Как и многие сравнения, vue подходит для небольших и доработанных проектов, а react больше подходит для более крупных проектов, но точка опоры этого вывода иная. Компоненты Vue можно использовать повторно из-за некоторой сложной логики и компонентов. Недостаточность приложения. Режим делает повторное использование и дизайн крупномасштабных проектов не такими хорошими, как React, но в небольших и сложных проектах vue — это более дружественный способ написания, более простой код и более декларативные инструкции.Большие преимущества и возможности.Наоборот, React может лучше компенсировать недостатки Vue в средних и крупных проектах, но это также требует, чтобы общая технология команды была более мощной. Дизайн и способности руководителя должны быть лучше, иначе все будет плохо. лучше, чем без дизайна. Есть некоторые сравнения, которые всегда думают, что vue имеет больше API и более гибок для написания окончательного кода, что затрудняет поддержку конечного кода.На самом деле, реакция может быть более гибкой, потому что у реакции почти нет API, поэтому возможен любой код.В команде 10 человек может быть 10 способов понять реакцию, и будь то управление состоянием или асинхронное промежуточное ПО плюс маршрутизация и т. д., сообщество реакции предоставляет больше возможностей, как выбрать модель и что план использования Одна из головных болей людей.
наконец
Оригинальный адрес:GitHub.com/Ван ВейДа/Но…
Я прочитал это, я думаю, что это не слишком много, чтобы поставить звезду~~~