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

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

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

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

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

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

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

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

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

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



Конференция JSWORLD
1–3 июня 2022 г. Конференция JSWORLD в театре Амстердама. Присоединяйтесь к нет. Первая конференция по JavaScript на планетеwww.jsworldconference.com



Состояние Вуэниона

Эван Ю — Создатель на Vue.js



Эван Ю
создатель Vue.jstwitter.com



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

Эван объясняет принятие Vue3 сообществом, обновления экосистемы с выпуском Nuxt3 RC с 21 апреля, бета-версию Vuetify 3, выпущенную 19 мая, и альфа-версию VitePress 1.0, а также текущую работу над Vite 3.0.

Принятие Vue 3

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

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

3

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

https://twitter.com/nuxt_js/status/1516888137716449280

3

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

ВитеПресс

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

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

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

Волар

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

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

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

Вайт 3.0 (в разработке)

Еще одна важная часть новой экосистемы — Vite, и команда работает над версией 3.

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

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

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

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

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

  • Перемещение самого Vite на полный ESM
  • Сборка SSR по умолчанию использует вывод ESM

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

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

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

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

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

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

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

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

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

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

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

Vue Core

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

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

Игровая площадка SFC

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

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

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

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

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

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

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

Вью 2.7

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

Объем

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

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

  • <script setup>

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

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

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

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

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

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

Кодовая база Vue 2 перенесена на 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> support.

Существует много логики — например. @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 или плагина Vite Vue как для Vue 2, так и для Vue 3, поэтому вам больше не нужно использовать отдельный плагин Vite Vue 2. или вы застряли на старой версии загрузчика Vue.

Он станет бета-версией после того, как <script setup> будет портирован, а предполагаемый выпуск — конец июня 2022 года.

Подразумеваемое

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

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

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

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

Вью 3.3

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

  • Стабилизируйте приостановку
  • Стабилизируйте преобразование реактивности
  • Улучшения SSR (ленивая / условная гидратация для асинхронных компонентов, улучшенные предупреждения о несоответствии SSR)
  • Поддержка импортированных типов в ‹настройке сценария› макросов на основе типов

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

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

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

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

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

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

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

<script setup>
import { ref } from 'vue'
const count = ref(0)
</script>
<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- Подключиться на уровне компонента

  • Встроить в существующее виртуальное приложение на основе DOM Vue 3.
  • Полностью совместим с существующими библиотеками

2- Подключиться на уровне приложения

  • Полностью удаляет среду выполнения Virtual DOM
  • Невозможно использовать компоненты на основе Virtual DOM
  • Подходит для чрезвычайно чувствительных к производительности случаев использования

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

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

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

Вы можете найти следующий разговор о Пинии здесь:



Получение большего от ваших магазинов Pinia — серия резюме Vue Amsterdam Conference 2022 — Second Talk
В этом выступлении Эдуардо рассказывает о некоторых внутренних компонентах Pinia, разбирается в них и узнает, как для улучшения нашего…medium.com