Добро пожаловать! Рад видеть вас в первой части моей серии резюме конференции Vuejs Amsterdam Conference 2022, в которой я делюсь с вами кратким изложением всех докладов.

Вы можете прочитать мою серию резюме JSWorld Conference 2022 (в четырех частях) здесь, где я подвел итоги всех докладов первого дня.

(Повторяющееся) введение

Спустя два с половиной года JSWorld и Vue Amsterdam Conference вернулись в Театр Амстердама между 1 и 3 июня, и у меня был шанс посетить эту конференцию впервые. Я узнал много нового, встретил много замечательных людей, пообщался с отличными разработчиками и прекрасно провел время. В первый день проходила конференция JSWorld, а во второй и третий дни — Vue Amsterdam.

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

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

Очень важный момент

Все, что вы прочитаете в этих нескольких статьях, является результатом усилий и времени самого оратора, а я лишь попытался выучить их, чтобы превратить в эти статьи. Даже многие предложения, написанные в этих статьях, являются именно тем, что они сказали или что они написали в Слайдах. Это означает, что если вы узнаете что-то новое, то только благодаря их усилиям. (Так что если вы увидите какую-то дезинформацию, вините их, а не меня, верно? xD)

И последнее, но не менее важное: я могу не вдаваться в технические подробности или живые коды в некоторых выступлениях. Но если вам интересно и нужно больше информации, дайте мне знать, и я постараюсь написать более подробную статью отдельно. Также не забудьте заглянуть в их Twitter/Linkedin.

Здесь вы можете найти программу конференции:

Конференция JSWORLD

Состояние Вьюниона

Эван Ты — создатель Vue.js

Доклад представлял собой обзор экосистемы и всех новых вещей, которые происходят. 7 февраля 2022 года Vue 3 стал версией по умолчанию наряду с новым сайтом Vuejs.org.

Эван объясняет принятие Vue3 сообществом, обновления Eco System с выходом Nuxt3 RC с 21 апреля, Vuetify 3 Beta, выпущенной 19 мая, и VitePress 1.0 Alpha, а также текущую работу над Vite 3.0.

Состояние Вьюэнион 2022 — Эван Ты

Принятие Vue 3

В настоящее время Vue 3 имеет около 800k еженедельных npm загрузок (измеряется по npm загрузкам @vue/runtime-core), что составляет +70% с момента запуска версии по умолчанию, и если мы посмотрим через год, то это 4x за последний год, и он составляет более 25% всех загрузок Vue, и это число, вероятно, станет намного больше к концу года.

Обновления экосистемы

Nuxt 3

Announcing Nuxt 3 first Release Candidate ✨

Since the beta release 6 months ago:
· 1000+ pull requests merged
· 900+ issues closed
· 160+ contributors

What an amazing community 💚https://t.co/ruyyd8o9XS pic.twitter.com/Z9aeQHeE5f

— Nuxt (@nuxt_js) April 20, 2022

Nuxt 3 сейчас находится в стадии RC. В него было вложено много труда, и ядро будет активно работать с Nuxt 3, чтобы стабилизировать некоторые финальные части, такие как suspense, который, надеемся, появится в 3.3.

Vuetify 3

Для многих людей Nuxt и Vuetify являются двумя основными компонентами, которые мешают им перейти с Vue 2 на Vue 3. Но теперь и Vuetify 3 вышел в бета-версию 19 мая, и это хорошая новость.

VitePress

VitePress только что выпустил альфа-версию 1.0 и был использован в новой документации по Vue.

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

Есть несколько небольших изменений, но мы очень рады, потому что VitePress действительно доказал, что с ним приятно работать, когда мы работаем над официальной документацией, он очень гибкий и очень мощный. Мы все еще обсуждаем, стоит ли нам официально сделать его заменой VuePress, просто назвать VuePress 3 или, может быть, он должен оставаться отдельным проектом, но идея в том, что если вы ищете генератор статических сайтов на базе Vue 3, VitePress будет официальной рекомендацией.

Volar

Если вы используете v3, вы, вероятно, знаете Volar, который является новым рекомендуемым расширением VSCode.

Начиная с марта Vue спонсирует Джонсона Чу, автора Volar, чтобы он работал над его улучшением полный рабочий день.

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

Vite 3.0 (WIP)

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

Как вы, возможно, знаете, node 12 вышел из эксплуатации, и это стало первоначальным стимулом для создания Vite 3, в которой отменена поддержка node 12.

Это не большая переработка, но она сопровождается рядом относительно небольших изменений.

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

Если вы используете только базовые возможности Vite, вы, скорее всего, не будете сильно затронуты, а если вы используете инструмент более высокого уровня, такой как Nuxt 3 или другие фреймворки поверх Vite, этот путь обновления, вероятно, будет более или менее прозрачным для вас, поскольку фреймворк более высокого уровня поглотит базовые изменения Vite.

Но все же существует вероятность доставки некоторых потенциально разрушительных изменений в обмен на большие преимущества:

• Переход самого Vite на полный ESM

• Сборка SSR по умолчанию для вывода ESM

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

• Неблокирующее обнаружение зависимостей + оптимизация

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

  Но первоначальная реализация имеет два ограничения:

  1. Фаза сканирования может быть дорогостоящей, если ваша кодовая база велика.
  2. Иногда на этапе сканирования не удается обнаружить зависимости, потому что в коде может появиться зависимость после того, как она будет преобразована фактическим плагином, поэтому приходится ждать, пока приложение загрузится.

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

  В версии 3.0 планируется сделать весь этот процесс бесшовным: Больше не нужна фаза сканирования, больше нет необходимости в позднем обнаружении зависимостей.

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

• Esbuild-powered dep optimization как для сервера разработки, так и для производственных сборок, более последовательное поведение между dev/prod

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

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

Ядро Vue

В течение апреля и мая они потратили примерно целый месяц на устранение ошибок в ядре v3, что привело к выпуску большого количества патчей (3.2.24~26), слиянию ~70 PRs и ~140 закрытых проблем.

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

SFC Playground

SFC Playground был рекомендованным способом воспроизведения ошибок для v3, но есть две категории ошибок, которые трудно воспроизвести в SFC Playground:

• Несоответствие поведения для <script setup> между производственным режимом и режимом разработки:

  В прошлом мы видели довольно много ошибок в этой категории, и большинство из них невозможно воспроизвести в SFC Playground, потому что SFC Playground по умолчанию работает в режиме production. Поэтому мы добавили переключатель, чтобы вы могли переключаться между режимом prod/dev, чтобы вы могли показать нам несоответствие поведения в случае, если оно имеет место.

  Итак, SFC Playground теперь поддерживает переключение между режимом prod/dev для компиляции <script setup>.

• Ошибка несоответствия гидратации SSR:

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

  Но теперь SFC Playground поддерживает воспроизведение SSR. Это означает, что весь процесс — полная компиляция → рендеринг → конвейер гидратации, работающий в браузере — происходит полностью в браузере, и все, что вам нужно сделать, это просто переключить кнопку.

Vue 2.7

Многие, кто застрял на Vue 2, спрашивали о нем, и он задерживался по разным причинам. Но наконец-то они начали работать над ним и добились большого прогресса.

Область применения

1. Перенос Composition API, чтобы он стал встроенным в Vue 2 вместо использования плагина @vue/composition-api.

   Вы сможете напрямую делать те же import { ref } from 'vue', что и в Vue 3. Кроме того, эти реализации более тесно интегрированы с системой реактивности Vue 2, поэтому они более эффективны, чем версия плагина.

2. <script setup>

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

   Если мы переносим API композиции на Vue 2, то имеет смысл перенести и настройку, поскольку это такая важная часть DX.

3. Улучшенная поддержка TypeScript

   Они не будут менять текущие поставляемые типы Vue 2, особенно для Vue extend, поскольку хотят сохранить полную совместимость типов для существующих проектов Vue 2.

   Вместо этого они собираются сделать отдельные типы Vue 3, которые также поставляются в типах, но вы получаете их, когда используете новый API defineComponent, доступный в Vue 3. defineComponent также позволит вам определять компоненты, но с типами, которые напрямую перенесены из Vue 3, что облегчит вам обновление до Vue 3, а также упростит для Volar одновременную поддержку Vue 2 и Vue 3.

Подготовительная работа

Кодовая база Vue 2 переведена на TypeScript!

Это огромный респект Pikax (Карлосу), который возглавил работу, сделал огромный pr, а также Дэвиду Уолшу, который помог с некоторой очисткой, так что я подхватил их работу и смог преобразовать всю кодовую базу в TypeScript.

Теперь это также монорепо pnpm, с модернизированной установкой тестов с Vitest.

Тесты теперь работают намного быстрее, чем в Vue 3, так что мне нужно действительно перенести тесты Vue 3 в Vitest!

Vitest — это новая и быстрая программа для проведения модульных тестов, работающая на базе Vite и имеющая полностью совместимый с Jest интерфейс.

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

Текущее состояние

Composition API уже полностью перенесен с фактически именованными экспортами и полной поддержкой типов, но с аналогичными ограничениями из плагина @vue/composition-api.

Vue 2.7 в настоящее время находится на стадии альфа-версии, 2.7.0-alpha.4 был выпущен на npm под дистрибутивным тегом v2-alpha, и они сосредоточены на тестировании совместимости и стабильности.

Следующие шаги

Следующим шагом будет перенос <script setup> поддержки .

Есть много логики — например, @vue/component-compiler-utils — которая разделена на отдельные пакеты и должна быть перенесена обратно в репо Vue 2, подобно тому, как это сделано в v3, что облегчает синхронизацию изменений по разным местам и сохраняет все согласованным.

Новая логика однофайлового компилятора будет представлена в виде vue/compiler-sfc так же, как и в Vue 3. Это также означает, что когда вы обновитесь до 2.7 и перейдете на новую настройку, она будет полностью совместима с существующими настройками. Вы можете просто удалить vue-template-compiler в качестве одноранговой зависимости и затем перейти на vue-loader 16+ или просто напрямую использовать @vitejs/plugin-vue, потому что компилятор однофайловых компонентов будет иметь точно такой же интерфейс, как и Vue 3.

Наша цель состоит в том, чтобы после обновления до 2.7 вы могли просто использовать последние версии Vue loader или Vite plugin Vue для Vue 2 и Vue 3, так что вам больше не нужно будет использовать отдельный Vite plugin Vue 2 или застрять на старой версии Vue loader.

Он достигнет стадии Beta после переноса <script setup> и предполагаемого релиза в конце июня 2022 года.

Последствия

2.7 будет последним минорным релизом Vue 2.x, и в Vue 2 не будет добавлено никаких новых функций.

Мы все еще будем исправлять ошибки, очевидно, мы позаботимся о том, чтобы у Vue 2.7 был гладкий путь обновления.

Vue 2 будет иметь 18 месяцев LTS, начиная с выпуска стабильной версии 2.7. Это означает, что срок службы Vue закончится к концу 2023 года.

Мы можем рассмотреть возможность предоставления расширенной поддержки в каждом конкретном случае, так что, скорее всего, это будет платная услуга. Так что если вы заинтересованы, вы можете зарегистрировать свой интерес на link.vuejs.org/xlts. Таким образом, мы хотим убедиться, что наша основная пропускная способность инвестирована в Vue 3 и в будущее, но также понимаем, что у некоторых пользователей Vue 2 могут быть причины оставаться на Vue 2 дольше, чем ожидалось, поэтому мы хотим убедиться, что есть хорошее решение для пользователей в этом сценарии.

Vue 3.3

Основные запланированные функции

• Стабилизация приостановки
• Стабилизация трансформации реактивности
• Улучшения SSR
  • Ленивая / условная гидратация для асинхронных компонентов
  • Улучшенные предупреждения о несоответствии SSR
• Поддержка импортированных типов в <script setup> type-based-macros

Работа над этой версией начнется после выхода стабильного релиза 2.7, и мы надеемся подготовить ее к 3 кварталу 2022 года.

Экспериментальная новая стратегия компиляции

Это действительно экспериментальная ранняя фаза исследования функции! Поэтому она даже может не приземлиться!

Большинство пользователей используют Vue через шаблон, и большинство из нас в своей повседневной работе взаимодействуют с Vue через однофайловый формат компонентов, а это исходный формат.

Vue как фреймворк имеет возможность компилировать файл в ванильный JavaScript и CSS, и этот шаг позволяет Vue быть суперкомпиляторно-ориентированным фреймворком.

Эта новая стратегия компиляции вдохновлена solid.js. Вместо компиляции шаблонов в функции рендеринга виртуального DOM, она компилирует их в императивный код инициализации DOM и установки реактивной привязки.

Представьте себе этот компонент:

// <script setup>
import { ref } from 'vue'
const count = ref(0)

<template>
    <div>
        <button
            :id="`foo-${count}`"
            :class="{ red: count % 2 }"
            @click="count++"
        >{{ count }}</button>
    </div>
</template>

Эта кнопка содержит несколько привязок.

Код вывода будет выглядеть примерно так:

import { ref, effect } from 'vue'
import {template, on, setClass, setAttr, setText } from 'vue/vapor'

const t0 = template(`<div><button>`)

export default () => {
    const count = ref(0)

    let div = t0()
    let button = div.firstChild
    let _button_class, _button_id, _button_text
    effect(() => {
        setClass(button, _button_class, (_button_class = {red: count.value % 2 }))
        setAttr(button, 'id', _button_id, (_button_id = `foo-${count.value}`))
        setText(button, _button_text, count.value)
    })
    on(button, 'click', () => count.value++)
    return div
}

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

Некоторые из преимуществ:

• Лучшая производительность v-for даже без v-memo
• Значительно меньшее использование памяти
• Значительно меньший размер базового времени выполнения (при полном отказе от использования)
• Потенциально более низкая стоимость абстракции компонентов

Стратегия внедрения:

1. Отказ от использования на уровне компонентов
   • Встраивание в существующее виртуальное приложение Vue 3 на основе DOM
   • Полная совместимость с существующими библиотеками
2. Внедрение на уровне приложения
   • Полностью отказаться от среды выполнения Virtual DOM
   • Невозможно использовать компоненты на основе виртуального DOM
   • Подходит для чрезвычайно чувствительных к производительности случаев использования

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

Конец первого разговора

Я надеюсь, что вам понравилась эта часть, и она может оказаться для вас такой же ценной, как и для меня.

Следующую статью о Pinia вы можете найти здесь.