Почему я рекомендую использовать JSX для разработки Vue3

JavaScript Vue.js

Что касается чрезвычайно оживленной области комментариев к этой статье, я вНаггетс.Талант/пост/691188…Сделайте единый ответ. Мне не нужно отвечать прямо в области комментариев. Я извиняюсь, если в предыдущем ответе есть какие-то крайние выражения, потому что это немного неуправляемо из-за того, что вы не публиковали сообщения слишком долго.

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

На всякий случай, если некоторые студенты действительно не читают официальную документацию, позвольте мне сначала упомянуть, что SFC пишется при написании компонентов Vue..vueфайл, этот один файл - SFC, полное имя - Single File Component, то есть один файл-компонент.

Прежде чем начать свое личное мнение, давайте рассмотрим несколько фактов:

Один:Определение Vue3 изначально поддерживает JSX, и существует исходный код Vue3.jsx.d.tsдля облегчения использования JSX.Я не знаю, что подумают студенты, когда увидят это. Моя первая реакция была:Спрос сообщества на JSX невелик, поэтому официальная поддержка JSX Vue3 будет направлена ​​вспять.

Во-вторых, версия AntDesign для vue3 в основном разработана с помощью JSX, а официальный плагин babel-jsx для Vue3 с самого начала поддерживается людьми из Ali. Хотя мне никогда не нравилась технология продвижения KPI Али, а текущая поддержка синтаксиса JSX не соответствует моим ожиданиям, хотя бы в том, что использование JSX-разработки — лучший выбор, я все же узнаю команду AntDesign.

Хорошо, говоря об этом, в основном, чтобы поставить некоторые факты за основу, чтобы некоторым студентам ничего не нужно было брать:

  • Ах, это все твое воображение, ты слишком самоуверен
  • Что бы вы ни думали, это бесполезно, наш Vue должен быть разработан с помощью SFC.

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

Хорошо, предисловие почти на этом, давайте проанализируем и проанализируем, почему вы должны выбрать JSX для разработки Vue.

Поддержка TypeScript

На самом деле первый пункт уже убийственный: для студентов, которые хотят использовать TypeScript для разработки приложений Vue3, это просто мировая проблема, которую SFC не может преодолеть.

Вкратце в одном предложении:TypeScript изначально поддерживает синтаксис JSX, но в принципе безнадежно, что TS официально поддерживает синтаксис шаблонов SFC..

Нет никаких сомнений в том, что TS становится все более и более важным в сообществе front-end, но любая команда front-end, у которой есть определенные требования к качеству кода в будущем, должна выбрать использование TS для разработки. И теперь в основном вы можете увидеть пакет на NPM и найти соответствующее определение TS.Теперь остается только стоимость разработки с использованием TS.Вы знаете синтаксис TS?В этом случае, поддерживать ли TS — важная причина, по которой режим разработки не может зайти далеко в будущем.

В настоящее время SFC может пройти толькоshimРазрешить TS импортировать.vueфайл, но определения одинаковы для всех компонентов SFC:

declare module '*.vue' {
    import { DefineComponent } from 'vue'
    const component: DefineComponent<{}, {}, {}, any>
    export default component
}

То есть для представленного вами компонента SFC TS не знает, какие реквизиты этого компонента должны получать. Таким образом, вы не можете пользоваться этими преимуществами TS:

  • Автоматические подсказки при разработке
  • Проверка TS во время компиляции, что позволяет обнаруживать проблемы как можно раньше.
  • Скомпилируйте компонент для создания определения вашего компонента (особенно важно для разработки библиотеки классов).

Конечно, вы скажете, что, поскольку Vue может официально разрабатывать синтаксис SFC, он, естественно, будет поддерживать эти функции. Я сказал, что это, безусловно, возможно, но это очень сложно и требует поддержки со многих сторон, и может даже потребовать помощи официальной команды ТС. Но я не могу придумать какой-либо официальной причины для TS поддерживать SFC, потому что это просто диалект, созданный самим Vue, который не используется в других сценариях. TS для всего сообщества. Я не думаю, что они будут рассматривать активно поддерживает SFC.

Затем некоторые студенты хотят спросить, не является ли JSX неродным синтаксисом JS, как он может получить официальную поддержку TS, есть ли какая-либо PY-транзакция между FB и Microsoft?

Это касается второго момента, разницы в гибкости между JSX и статическими шаблонами.

JSX на самом деле не диалект

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

Вкратце в одном предложении:JSX не расширяет синтаксис JS, он просто сокращает способ написания JS! Его суть — синтаксический сахар JS.

Так же, как синтаксический сахар, добавленный es6, например

const a = 1
const b = 2

const obj = { a, b }

// 其实就等价于
const obj = { a: a, b: b }

Этот способ написания не расширяет возможности JS, он просто упрощает способ написания, и то же самое верно для JSX.

JSX на самом деле является вызовом метода. Он имеет взаимно однозначное соответствие с JS. Давайте рассмотрим пример:

const element = <div id="root">Hello World</div>

Синтаксис JSX здесь на самом деле:

const element = createElement('div', { id: 'root' }, 'Hello World')

И JSX — это не более того, так что JSX — это простоСинтаксический сахар для написания вложенных вызовов функций, который сам по себе больше ничего не расширяет.

Но SFC отличается.

SFC определяет не только синтаксис, но и файлы.

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

  • В файл может быть записан только один компонент
  • Фрагменты узла могут быть записаны только в шаблоне, что очень негибко.
  • Привязка переменных может получить толькоthisДля вышеуказанного контента нельзя использовать глобальные переменные (часто нам приходится монтировать глобальные переменные вthisначальство)

давайте немного поговорим

В файл может быть записан только один компонент

Честно говоря, это очень и очень неудобно, ведь часто, когда мы пишем страницу, нам часто приходится разбивать какие-то мелкие фрагменты узлов на мелкие компоненты для повторного использования (если у вас сейчас нет такой привычки, то может быть из-за ограничения SFC, из-за которых вы привыкли записывать все в один файл).

Богатое решение css-in-js в экосистеме React — хороший пример, который мы можем использовать:

const StyledButton = styled('button', {
    color: 'red',
})

Если на нашей странице необходимо использовать определенный стиль кнопки, очень часто ее инкапсулируют в файле страницы таким образом. Поскольку нет необходимости разделять этот компонент, и он не является компонентом многократного использования, для его разделения потребуется еще один раз.import.

В экосистеме Vue практически нет зрелого решения css-in-js, что собственно и связано с этим ограничением.

Другой пример. Например, мы инкапсулируем компонент ввода. Мы надеемся экспортировать компонент пароля и компонент Textarea одновременно, чтобы пользователи могли использовать его в соответствии с их фактическими потребностями. Эти два компонента используют компонент ввода для внутреннего использования, но только настроить некоторые реквизиты:

const Input = { ... }

export default Input

export const Textarea = (props) => <Input multiline={true} {...props} />

export const Password = (props) => <Input type="password" {...props} />

Его можно реализовать очень просто на JSX, но при сдаче SFC, возможно, придется принудительно разбить его на три файла, а для удобства, возможно, придется добавить еще одинindex.jsЧтобы экспортировать эти три компонента, представляете, сколько это труда?

Фрагменты узла могут быть записаны только в шаблоне, что очень негибко.

Я не знаю, сколько студентов видели код, скомпилированный по шаблону Vue. По моему опыту, они, возможно, не видели более 50% (оптимистичная оценка). Я полагаю, что если вы этого не понимаете, вы можете попробовать. , один раз.

Зачем это смотреть? Потому что после того, как вы его прочитаете, вы обнаружите, что контент, похожий на HTML, который вы пишете в шаблоне, не имеет вообще никакого отношения к HTML, и они также будут скомпилированы в результат, аналогичный тому, который скомпилирован JSX.

{
    render(h) {
        return h('div', {on: {}, props: {}}, h('span'))
    }
}

Такие результаты и здесьhРезультатом вызова функции является VNode, базовая единица узлов в Vue. Так как эти единицы являются объектами, конечно, они могут быть переданы как параметры. Другими словами, теоретически они могут пройтиpropsПередает узлы в качестве параметров другим компонентам.

Эта практика очень распространена в React и называетсяrenderProps, и это очень гибко:

const Comp = () => <Layout header={<MyHeader />} footer={<MyFooter />} />

Но из-за ограничений шаблона SFC нам сложно писать ноды на пропсах в SFC:

<template>
    <Layout :header="<MyHeader/>"></Layout>
</template>

Это невозможно написать так, потому что SFC определяет:headerПривязки могут принимать только выражения js и<MyHeader/>Очевидно нет.

Поскольку передача реквизита невозможна, Vue изобрел концепцию слот-слота.

Хотя мы продолжаем говорить, что Vue прост, на самом делеScopedSlotsКогда-то для новичков понимание Vue стало кошмаром, и многие студенты были опустошены этим круговоротом.

мы смотрим на одинScopedSlotsпример:

<template>
    <Comp>
        <template v-slot:scope="ctx">
            <div>{{ctx.name}}</div>
        </template>
    </Comp>
</template>

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

<Comp scope={name => <div>{name}</div>} />

Мы только что позвонилиscopeРеквизиту передается функция, которая принимаетnameсвойства, вCompЭта функция будет вызываться внутри и передаваться вname. Короче говоря, мы передаем функцию, которая строит фрагменты узлов, это так просто.

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

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

Привязка переменных может получить толькоthisВышеприведенный контент не может использовать глобальные переменные

Это отражается в двух аспектах: во-первых, если некоторые фиксированные данные, которые мы определяем глобально, должны использоваться в компоненте, они должны быть переданы черезthisмонтируется на компонент.

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

И этого больше нет в JSX:

const citys = []

const Comp = () => {
    return citys.map(c => <div>{c}</div>)
}

Другим аспектом является использование компонентов, В SFC компоненты должны быть зарегистрированы заранее, потому что то, что мы пишем в шаблоне, может быть только строками, а не конкретными переменными компонента. Тогда компонент в шаблоне и реальный объект компонента могут быть связаны только путем сопоставления строк. Это вызывает следующие проблемы:

  • Добавьте шаг регистрации компонентов и увеличьте объем кода
  • Регистрация через строковое имя, естественно, вызовет возможные конфликты
  • Компонент синтаксического анализа шаблонов поддерживает различные стили, такие как<MyComp>а также<my-comp>, что может легко привести к проблемам с разными стилями

В JSX такой проблемы нет, потому что JSX использует ссылки на компоненты напрямую как параметры:

const Comp = {...}

const App = () => <Comp />

нужно пройтиdirectiveрасширить возможности

На самом деле, из вышеизложенного видно, что в дополнение к проблемам самой SFC, использование Vue строковых шаблонов также принесет много проблем с гибкостью. Самым прямым доказательством является то, что Vue используетdirectiveДля расширения функции (конечно, это не придумано Vue, у старого шаблонизатора есть похожие проблемы).

зачем говоритьdirectiveЭто крайняя мера? Потому что статические шаблоны не могут обрабатывать логику. Возьмем в качестве примера цикл списка, в JS мы можем легко передатьmapфункция для создания списка:

const list = arr.map(name => <span key={name}>{name}</span>)

И поскольку JSX сам по себе является вызовом функции, приведенный выше код также очень естественно комбинировать с JSX:

const App = () => (
    <div>
        <Header />
        {arr.map(name => (
            <span key={name}>{name}</span>
        ))}
    </div>
)

Приведенный выше пример соответствует JS следующим образом:

const App = () =>
    createElement('div', {}, [
        <Header />,
        arr.map(name => createElement('span', { key: name }, name)),
    ])

Это все еще потому, что JSX — это просто синтаксический сахар для JS, все, что можно реализовать в JS, можно реализовать в JSX.

Шаблон SFC скомпилирован на основе строк, которые сами по себе являются строками, мы не можем прописать их прямо в шаблонеmapдля перебора узлов (конечно, мы можем написать, где можно получить выражения, напримерv-onв).

Итак, мы не можем зациклить узлы, нужна такая функция для отображения списка, что нам делать? Это придумать флаг, чтобы сообщить компилятору, что здесь нужен цикл, что и отражено в Vue.v-forинструкция.

Студентам, возможно, придется спросить, так как Vue может достичьv-for, почему бы просто не реализовать список циклов выражений напрямую? Конечно, он может это сделать, но он точно не выберет это, потому что цена слишком высока. Если он хочет это сделать, он хочет реализовать JS-движок, но на самом деле много контента в нем ненужно.v-forНа самом деле, его можно применить к большинству ситуаций.

но сv-forнужноv-if, то позже потребуются различные другие способности, что и является процессом возникновения и развития диалекта.

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

Суммировать

Выше приведен мой анализ того, что выбрать для разработки: JSX или SFC.На самом деле проблема с SFC в том, что он не поддерживает JS. Его грамматика была изобретена им самим, и ему понадобился компилятор, реализованный на JS, чтобы наконец запустить ее в среде JS, что по сути является изобретением. Мы не можем отрицать, что у изобретения есть преимущества, но мы не можем просто игнорировать проблему.Если мы не сможем принять JS, естественно, будет трудно полностью использовать преимущества JS-сообщества. И сообщество JS процветало, и появлялись полезные инструменты,И SFC хочет использовать эти инструменты сообщества JS и должна реализовать их самостоятельно., мы можем подсчитать следующие SFC, которые совместимы

  • vue-загрузчик для веб-пакета
  • eslint-plugin-vue для eslint
  • rollup-plugin-vue для сворачивания
  • vue-jest для шутки
  • Vetur используется для напоминаний кода

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

На данном этапе, когда Vue3 готовится к разработке, мы все еще надеемся, что сообщество Vue сможет использовать лучший и более стандартизированный способ разработки. На самом деле, если мы будем использовать JSX для непосредственной разработки Vue3, мы обнаружим, что во многих случаях нам не нужно его использовать.emit,attrsэти понятия, Даже если JSX-плагин Vue3 его поддерживает, мы даже можем его выбросить.slots.

Однако, поскольку Vue3 должен считаться совместимым с Vue2, Vue3, который сам по себе имеет хороший потенциал, всегда, кажется, сжимается, о чем следует сожалеть.

Наконец, я верю в потенциал Vue3 и всегда буду активен в сообществе Vue3.Если вы хотите получать больше высококачественных учебных материалов по Vue3, вы можете подписаться на BestVue3, и сейчас создается больше высококачественного контента!

Эта статья была впервые опубликована вBestVue3, поиск в общедоступной учетной записи WeChatBestVue3Вы можете обратить внимание и изучить Vue3, не теряясь.

Категории