Smashing Podcast Episode 26 С Натальей Теплухиной: Что нового в Vue 3.0?

В этом выпуске подкаста мы говорим все о VueJS. Что нового в версии 3.0 и насколько сложно будет выполнить миграцию? Дрю Маклеллан разговаривает с членом основной команды Натальей Теплухиной, чтобы выяснить это.

Показать примечания

• VueJS
• Руководство по переходу на Vue 3
• Наталья в Твиттере
• личный сайт Натальи

Еженедельное обновление

• Различные способы оформления страниц цифровых продуктов
  автор Сюзанна Скакка
• Модульное тестирование в нативных приложениях React
  автор Fortune Ikechi
• 5 способов, которыми Google Analytics помогает веб-разработчикам в дизайне UI/UX
  автор Клара Буэнконсехо
• Понимание дженериков TypeScript
  автор Джейми Коркхилл
• Как использовать движение лица для взаимодействия с типографикой
  автор Эдоардо Кавацца

Стенограмма

Дрю Маклеллан. Она страстный веб-разработчик, эксперт Google Developer, спикер и автор конференций. В настоящее время она является штатным фронтовым инженером в GitLab, но вы, возможно, знаете ее лучше всего как члена основной команды Vue JS. Так ясно, что она разбирается во Vue лучше, чем кто-либо другой. Но знаете ли вы, что однажды она научила кенгуру петь. Друзья мои Smashing, встречайте Наталью Теплухину.

Дрю: Привет, Наталья, как дела?

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

Дрю: Ладно, я постарался. Но важный вопрос в том, вы Smashing?

Наталья: Конечно.

Дрю: Это хорошо. Итак, я хотел поговорить с вами сегодня о некоторых действительно захватывающих новостях, которые у нас есть в сентябре с выпуском Vue 3.0. Это был крупный выпуск с точки зрения номера версии, но это действительно большой выпуск для Vue, и он находился в разработке в течение довольно долгого времени, не так ли?

Наталья: Есть. Я думаю, что мы впервые анонсировали третью версию в 2018 году. Я думаю, что она была анонсирована весной, и настоящая работа началась, я имею в виду, что идеи были весной, настоящая работа началась осенью 2018 года. И, кажется, официально это было заявлено на Лондонской конференции, которая состоялась в октябре 2018 года. Активная работа заняла два года. И это много, если подумать, предыдущая версия была выпущена в 2016 году. Таким образом, половина этих четырех лет также была посвящена работе над Vue 3.

Дрю: Что послужило мотивирующим фактором при принятии решения о создании новой основной версии? Было ли это своего рода сознательным решением, что мы будем работать над основной версией, мы будем работать над Vue 3, или это было просто накопление изменений, которые просто требовали увеличения версии?

Наталья: Нет, я думаю, идея создать новую версию возникла из-за нескольких очень важных моментов. Так что в первую очередь была мотивация к изменению реактивности. Предыдущий был построен на Object.defineProperty. И у него было несколько предостережений, они все задокументированы, но все же. Знаете, даже если вы задокументируете то, что люди не должны делать, они все равно это сделают. И вам нужно будет указать им на документацию. Кстати, документацию никто не читает. Просто почему-то так бывает. Пока вы не укажете людям, что это не существует в документах, оно существует. Но ладно. Мы вас все равно научим. Так что реактивность была одной из вещей.

Наталья: Спектакль был следующим. У Vue 2 все еще была и есть не самая плохая производительность, но у нас было несколько идей, как сделать Vue быстрее. А также была одна болевая точка для определенной части нашей, скажем, аудитории, людей, которые используют Vue. Это был TypeScript. Внутренне Vue 2 был написан на Flow, который по-прежнему строго типизирован, но набор текста с помощью TypeScript был настоящим кошмаром, особенно если вы работаете с нашим управлением состоянием Vuex. Это снова была огромная часть. И последнее: нам как бы не хватило функциональности абстрактной логики с точки зрения не компонентов, а составных частей логики. Как помощники по функциям и т. д., но они также должны иметь возможность включать действия зрителя. Хорошим примером здесь могут быть React Hooks, поскольку они позволяют вам абстрагироваться от частей функциональности, чего явно не хватало во Vue. И я знаю, что сейчас это звучит как «Вы украли функцию у React». На самом деле нет. Я считаю, что перекрестное опыление идей — большая и приятная часть нашей экосистемы, а также помогает разработчикам переключаться между фаворитами, верно?

Наталья: Итак, мы работали над этими основными функциями, чтобы создать основную версию Vue 3.

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

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

Наталья: Я категорически против того, чтобы типа «Воруете идеи». Это не воровство, это просто перекрестное опыление.

Дрю: Точно, да. Вы упомянули, что переход на TypeScript, поэтому сам Vue 3 теперь написан с использованием TypeScript, это правильно?

Наталья: Да, так и есть. И поверь мне, Дрю, я писал документацию, небольшой документ о том, как использовать Vue с TypeScript. И я подумал, ладно, наверное, как Vue 2. И я так сильно усложнил документ, что мне казалось, что я набираю все явно. Вроде хорошо все напечатано. Типы вижу, так что мой тс-линк доволен, пока все хорошо. И тут один из наших разработчиков, работавший с TypeScript, сказал: «Вам не нужно этого делать». Типа как, как? «Вам не нужно делать явные типы данных. Вы просто даете ему начальное значение, и ts-link знает его номер. Оно уже напечатано». Мол, как так? «Я удалил из документа 90% явных типов. Есть только две вещи, которые вам действительно нужно ввести: прокси компонента и вычисляемые свойства. Они по-прежнему требуют возвращаемых типов. Но остальное вроде как, набирается автоматически, просто напишите компонент с помощью метода, который мы называем define component. Вот и все. Это напечатано.

Наталья: Было такое, просто работает. Что касается меня, а в прошлом я много работал с Angular, у меня Стокгольмский синдром для TypeScript. Все должно быть прописано явно. Я имею в виду, если у вас сложные типы, конечно, вам нужно будет писать интерфейсы, но так работает TypeScript. Тем не менее, работать с TypeScript намного проще прямо сейчас с Vue 3.

Дрю: Так что это здорово, так что это преимущество как для проекта Vue Core, так и для разработчиков, которые создают приложения с использованием Vue, потому что теперь они могут хорошо использовать TypeScript в своих приложениях с Vue, где они не могли с 2.0, ну, с любой версией. 2.0 так легко. Те, кто знаком с сообществом Vue, знают, что создатель Vue Эван Ю по-прежнему очень активно руководит проектом. Как работает основная команда? Как он структурирован, когда дело доходит до процесса разработки? Это еще не все, Эван?

Наталья: Это такой отличный вопрос, Дрю, потому что годами буквально люди говорили о Vue как, я цитирую это, и это прозвучит резко, но, извините, это типа «Фреймворк одного китайца, как китайский фреймворк даже». . И я имею в виду, что даже с Vue 1.X уже была команда, и была большая команда за Vue 2 и еще большая команда за Vue 3. Дело в том, что у всех нас разные обязанности, когда мы говорим о Vue.

Наталья: Есть люди, которые работают над Core, и это не только сам Эван, он, безусловно, делает большую часть работы над Vue Core, и он же ведет проект. Но есть люди, которые работают в Vue Core, и их вклад абсолютно бесценен. И есть несколько новых людей, присоединившихся к команде Vue, которые работают в Core. И есть также небольшие команды, работающие над экосистемой, есть люди, которые работают над Pure Router, такие как Эдуардо, есть люди, работающие над Vue CLI, над Vuex, а также над документацией.

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

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

Дрю: Для слушателей, которые, возможно, не привыкли к Vue, но, возможно, знакомы с другими реактивными фреймворками, такими как React, Angular и так далее. Каковы большие изменения заголовков в Vue 3 и, в частности, какие проблемы они пытаются решить? Вы упомянули композицию ранее как одну из таких вещей, это одно из больших изменений?

Наталья: Да, это одно из самых больших изменений, и на самом деле это одна из вещей, которые, прежде всего, как позвольте мне сделать здесь четкое заявление. API композиции является чисто аддитивным. Дело не в том, что вам нужно переписывать свои компоненты, вы можете добавить к ним TypeScript. Или вы можете предпочесть использовать весь синтаксис, теперь мы называем его Options API, и в этих условиях для вас ничего не изменится. Когда мы говорим о новом API, это не критическое изменение. Я просто хочу подчеркнуть это на самом деле, это очень важно сказать, потому что, когда они впервые объявили о Composition API, это был ужасный момент.

Наталья: Я думаю, что мы не очень красиво описали изменения и сделали вид, что стандартной сборкой будет Composition API. Это полностью наш недостаток, и варианты были такими, может быть, мы откажемся от него в будущих сборках, а не в Vue 3, очевидно. И если есть какие-то шансы, что люди прочитают то, что вы сказали неправильно, они прочитают это неправильно.

Наталья: Сразу после этого заявления, именно RFC, где мы только что предложили изменение, Reddit взорвался. Reddit был заполнен типа: «О, мой бог. Мне нужно будет все написать. Боже мой. Vue — это новый Angular. Они все сломают». И был парень, который создал статью на dev.to под названием «Самый темный день Vue». Это был самый черный день, если честно. Мы чувствовали себя так, но я как бы пытался бороться с этим в своем собственном Твиттере, например: «Люди, которыми мы на самом деле не являемся… Они говорили, что мы начали изменять RFC, я думаю, что Эван начал изменять RFC, не объявляя об изменениях. Поэтому он сказал: «Я просто быстро перепишу это. Давай как протолкнемся в мастер». Люди были без ума от этого. Поскольку они спорили об определенных моментах, вы просто обновляете страницу, и этих моментов больше не существует. Вы чувствуете, что я дурак или просто… Какого черта? Я имею в виду, это было прямо там. Я это помню. И я считаю, что наша коммуникационная стратегия могла бы быть лучше, и это не мы.

Наталья: Сейчас каждый раз, когда я говорю о композиции, это чисто аддитивно, люди. Это просто приятная особенность. Вы можете использовать его, вы можете не использовать его, вы не обязаны. Просто… Он существует.

Дрю: С какой проблемой может столкнуться кто-то, когда Composition API — это новая вещь, которая помогает им решить эту проблему? Какую проблему он решает?

Наталья: Представьте себе компонент, внутри которого есть несколько фич. Допустим, это поиск и сортировка. Допустим, мы ищем определенный список и пытаемся его отсортировать. Это уже две разные функции, и дело с компонентами Vue в том, что они разделены на основе опций, а не на основе логики. Представьте, что ваш поиск, вероятно, имеет запрос, потому что вам нужно сделать запрос для поиска и массива результатов. А это два реактивных свойства. Что касается вашего компонента, вы помещаете их в параметр, который называется данными. И, очевидно, вам нужен какой-то метод для выполнения сортировки. Может, нажатие кнопки, может, что-то еще, что-то, что запускает поиск. Вы создаете метод. А для сортировки нужно что-то строить по параметрам сортировки, еще одно реактивное свойство. Затем вы выполняете некоторые вычисления, чтобы отсортировать результаты.

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

Наталья: Какие возможности у нас были в Vue 2.0? Первый вариант назывался миксин, а миксин — это просто объект, который может содержать те же свойства, что и компонент, и мы смешиваем их с компонентом. Звучит хорошо, я могу просто переместить туда весь свой поиск, и в чем проблема? Есть несколько. Во-первых, это совершенно не гибко. Если я хочу найти определенную конечную точку и перемещаю ее в миксин, это будет единственная конечная точка, которую я могу искать. Миксины не принимают параметры. Я создал миксин, он полностью статичен. Вторая проблема заключается в том, что миксин смешивается, что означает, что для определенных свойств это происходит как слияние. Например, если вы создали хуки, они будут объединены. Вся логика в хуке жизненного цикла из компонента миксина объединяется вместе. Но если у вас есть свойство данных, холодный запрос в миксине и случайно у вас есть то же самое в компоненте, компонент имеет приоритет. Он будет переопределен. У вас не будет предупреждений. Абсолютно. Это просто произойдет, и вы не будете знать, что это произошло.

Дрю: Весь спектр полностью перемешан?

Наталья: Да, полностью. Нет никаких шансов, что вы увидите, а также миксины - очень неясный источник. Вы просто импортируете миксин с именем и помещаете его для просмотра свойств компонента, вот и все. Это очень имплицитно, и я говорю об этом с точки зрения собственного опыта. У нас есть логика в GitLab, где компонент содержит два миксина, и каждый из этих двух миксинов содержит еще один миксин. И вот оно, вот свойство, которое нужно проверить, и его нет в компоненте. Давайте углубимся, миксин первого уровня. Этот не содержит его, и этот тоже не содержит его. Где это? Вы ныряете глубоко, еще глубже в кроличью нору, просто чтобы найти это свойство, и тестирование также становится кошмаром.

Наталья: Миксины — это очень, скажем так, тупой способ извлечения логики. Это просто, это ясно, это очень легко получить. Это приносит вам так много проблем, если вы хотите работать с этим на продвинутом уровне. Следующим способом абстрагирования логики в Vue 2.0 были компоненты без рендеринга. В Vue компонент может содержать слот. По сути, это часть, в которую вы можете поместить что-либо из родительского компонента. Небольшое окошко, точнее щель. И есть идея слотов с ограниченной областью действия. Представьте себе дочерний компонент, который может предоставить свою область действия обратно родительскому элементу, и содержимое слота будет иметь к этому доступ. Представьте, что у меня есть компонент со слотом, и компонент выполняет всю логику поиска, скажем, поиск, который имеет конечную точку с прошлыми параметрами. Наш дочерний компонент, например, поиск, а затем предоставляет эту часть своей области видимости родительскому компоненту. Это результаты поиска. Наслаждаться. Звучит неплохо. Звучит определенно лучше миксинов. Мы можем проверить параметры. Логика здесь явная, мы что-то возвращаем. Проблемы? Есть несколько.

Наталья: Во-первых, вы создали свой экземпляр компонента. Это не самая дешевая операция в мире. Вторая часть, это время выполнения. Компонент работает только во время выполнения, и это означает, что открытое свойство этого компонента будет доступно только в слоте, который вы предоставили ему как область слотов, поэтому результаты поиска доступны только в небольшой части вашего шаблона. Если вы хотите поиграть с дискретной частью компонента, у вас нет доступа к ней. Это время выполнения. Эта логика не могла действовать, если вам нужно реактивное состояние где-то еще. Конечно, он может создавать помощника, например чистую функцию, и возвращать результаты, но что, если мне нужно работать с реактивными свойствами? Так был создан Composition API. С Composition API вы можете иметь автономное реактивное состояние. Реактивное состояние больше не просто часть компонента. Вы можете сделать любой объект или примитив реактивным. И вы можете показать его родителю, это очень явно.

Наталья: Выставлено все имущество, которое вы хотите вернуть родителю. Это явно, вы можете нажать на это, вы можете увидеть, где это, что это такое и так далее. И самое приятное, если вы включите часть Composition API в старый добрый компонент, который имеет методы данных, свойства компьютера и т. д., он просто работает. Он просто отлично работает, вы просто добавляете несколько реактивных свойств и методов в свой компонент, и вы также можете использовать их со старыми API опций.

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

Наталья: Да, безусловно, потому что Composition API, если мы исключим из этого хуки жизненного цикла, потому что вы также можете запустить другой хук жизненного цикла в составном. На самом деле это чистая функция. У вас есть S-параметры, вы что-то делаете, и помимо зацепок жизненного цикла все еще есть побочные эффекты. А тестирование чистых функций, как известно, наверное, проще всего. Это просто черный ящик, у вас есть S-параметры, вам есть что возвращать.

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

Дрю: Я всегда думаю, что при выборе построения поверх фреймворка большое внимание уделяется стабильности его API с течением времени. Может быть, стабильность — не то слово, но я думаю, что многие из нас были поражены тем, что строили поверх фреймворка, а затем подвергались серьезной переработке и оставляли нам приложения, которые либо требовали огромных инвестиций для миграции, либо просто оказывались привязанными. на старую версию фреймворка, которая больше не поддерживается. Это ужасная ситуация. Сколько сна я потеряю, перенося большой проект с Vue 2 на Vue 3?

Наталья: Во-первых, поверхность API на 90% такая же, как была. У нас было не так много устаревших вещей или устаревших фильтров, которые можно заменить устаревшими концентраторами событий. Если вы хотите использовать EventEmitter, вам также нужно будет заменить представление, основанное на некоторой внешней библиотеке. Это большие изменения, но если говорить о миграции… Позвольте мне прояснить, я сейчас очень расстроен, потому что, с одной стороны, я член основной команды Vue JS. С другой стороны, я штатный инженер в большом проекте, использующем Vue. Если вы собираетесь начать миграцию прямо сейчас, я бы не рекомендовал этого делать. Прежде всего, экосистема еще не выпущена, я имею в виду, если мы говорим о базовых библиотеках, таких как Pure Router, PUX, Vue CLI, они в хорошей форме, но они все еще являются кандидатами на выпуск, а не релизами. И если мы говорим о других экосистемах, таких как, может быть, не основные библиотеки, библиотеки компонентов пользовательского интерфейса, может быть, некоторые библиотеки проверки формы, они не готовы, в основном, для Vue 3. И если у вас большой проект, у вас так много зависимостей, которые вам нужно уход. Так что это будет сложная вещь.

Наталья: Какие варианты? У вас большой проект, и вы хотите использовать все возможности Composition API. Как этого добиться? В первую очередь мы планируем выпустить LTS-сборку Vue 2.0, Vue 2.7. Это будет включать в себя множество предупреждений об устаревании, так что вы сможете увидеть, что будет устаревшим, как это реорганизовать, чтобы не сломать его с Vue 3. Таким образом, вы все еще будете технически использовать Vue 2, но вы будете готовить Vue 3 в любом случае, потому что у вас есть все предупреждения.

Наталия: Во-вторых, мы будем использовать инструмент миграции, который сможет просто запустить его, и он будет работать как кодмод, заменяя вещи, относящиеся к Vue 2, альтернативами Vue 3. Конечно, идеальных кодмодов не бывает. Мы стремимся, в первую очередь, производить замены, когда это возможно, но также показывать предупреждения, когда устаревание не может быть легко обработано. Codemod сможет распознать вещь и выдать предупреждение, но не заменит ее сам по себе. Это похоже на большой план, и к моменту выпуска Vue 2.7, и я думаю, что прямо сейчас их предполагаемое время прибытия — декабрь, если я правильно помню, мне нужно будет проверить дорожную карту, но я думаю, что это декабрь.

Наталья: Экосистема тоже будет более-менее готова. Если у вас есть большой проект с Vue 2.0, просто подождите еще немного, пока Core не стабилизируется, потому что даже если вы создаете идеальную библиотеку, ей все равно нужно некоторое время для стабилизации, потому что люди начинают это использовать, люди начинают сообщать об ошибках. Если вы собираетесь использовать его для домашних проектов и сообщать об ошибках, пожалуйста, вы можете это сделать. А после этого будет хороший плавный переход на Vue 3.

Дрю: Итак, инструмент миграции, о котором вы упомянули, звучит довольно интересно. Это в основном инструмент статического анализа, который просматривает ваш код и…

Наталья: Да-да-да, это код или инструмент. Сейчас он доступен в очень ограниченном виде. Он доступен в виде подключаемого модуля Vue CLI. Если у вас есть проект на основе Vue CLI, вы можете запустить обновление Vue и посмотреть, как работает этот инструмент. Он пока не в том виде, в каком мы хотим его видеть. К сожалению, я не работаю над проектом, построенным на Vue CLI. Мне нужно было бы подождать и проверить, что происходит, но, например, GitHub, мы уже предприняли несколько шагов даже без инструмента миграции для подготовки, потому что мы знаем, что устарело. На самом деле это указано в документации Vue 3.

Наталья: Есть руководство по миграции. Вы можете увидеть все критические изменения и вещи, которые устарели, и вы уже можете работать над частью из них даже на кодовой базе Vue 2.0. Например, в Vue 2.6 мы изменили синтаксис слотов. Синтаксис для слотов области устарел, но не запрещен, он все еще существует. Он выдает предупреждение, но вы можете запустить его. И, конечно же, с кодовой базой, которой было семь лет, никто не заботится о замене всего устаревшего синтаксиса, если он просто работает. Предупреждений в производстве нет. Слоты работают. В разработке типа: «О, я вижу какое-то предупреждение в консоли. Может быть, 20 из них, хорошо. Он желтый, а не красный. Мне все равно».

Наталья: Вы знаете, это случается со всеми. Мы создали огромную эпопею, чтобы работать над этим. Найти все текущие наборы старого синтаксиса. Мы прилагаем усилия, чтобы заменить наш EventEmitters, опять же, семилетний проект, не судите нас. У нас есть эмиттеры событий. GitLab работал над EventHub. Мы заменили развлечения на основе Vue внешними библиотеками. Я бы рекомендовал сделать то же самое. Просмотрите руководство по миграции, чтобы проверить, что уже можно заменить и какие изменения вы уже можете внести, чтобы подготовиться и начать работу над этим.

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

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

Наталья: Также, если вы хотите поиграть с каркасом своего проекта, прямо сейчас Vue CLI поддерживает два режима. Вы можете создать проект Vue 2, вы можете создать проект Vue 3. И обязательно попробуйте хотя бы. Это хороший способ и для нас, потому что во время игры вы обнаруживаете ошибки, сообщаете об ошибках, мы пытаемся их исправить и так далее.

Дрю: В документах и ​​на дорожной карте разработки я вижу упоминание о сборке миграции. Это что-то отличное от того, о чем мы говорили, или это то, о чем мы говорим?

Наталья: Нет-нет, все то же самое. Это то же самое, и оно должно быть готово, но на данный момент, если вы планируете миграцию, основной путь — просто прочитать документы и следовать тому, что там сказано, потому что мы определенно прилагаем усилия, когда у нас нет инструмента миграции, команда документации пошла вперед и создал подробное руководство о том, что такое изменение, почему оно было сделано и что на самом деле является заменой здесь.

Дрю: Да, в документах есть довольно подробное руководство по миграции как часть документов Vue 3, и в нем упоминается очень много изменений, которые необходимо перенести. Я предполагаю, что некоторые из них не повлияют на каждый проект. Многие из них были по сути крайними случаями для многих людей. Это справедливо?

Наталья: Да, большая часть из них, например, фильтры, определенно являются крайним случаем, потому что даже в GitLab с уже в третий раз кодовой базой семилетней давности и большой. У нас было одно или два появления фильтров, и они больше не использовались. Хорошо, что мы искали их и полностью удалили, потому что типа «О, неиспользуемый код» и опять же, кого это волнует, он просто существует.

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

Дрю: Приятно знать. Релизы 3.0, выпущенные вместе с Vue, я имею в виду, что вы упомянули экосистему и все, что с ней связано, Vuex и все эти другие части экосистемы, которым необходимо перейти на этот уровень. Поэтому в настоящее время на веб-сайте большая кнопка «Начало работы» по-прежнему переходит на Vue 2? Такое ощущение, что Vue 3 был выпущен, но не с полной уверенностью. Но из-за этой проблемы с экосистемой это все еще так?

Наталья: Нет, я думаю, вы только что нашли ошибку, давайте я просто быстро проверю. Нет, начало работы указывает на Vue 3, все в порядке. Я имею в виду, что если вы зайдете на vuejs.org, он укажет на вторую версию. Это сделано намеренно, потому что мы планировали заменить его поддоменом, таким как Vue 2, который находится в стадии разработки, но пока мы решили оставить vuejs.org там, где он есть, и создать Vue 3, поэтому на vuejs есть баннер. орг. Если вы пойдете в любой doc-

Дрю: Да, наверху есть крошечный баннер.

Наталья: Да вроде маленькие.

Дрю: Ага.

Наталья: Думаю, надо увеличить. Больше и с лучшим цветовым контрастом. Мое чувство доступности остается таким: «О, здесь нет ничего контрастного».

Дрю: Это хорошие новости. Если кто-то начинает, может быть, небольшой проект, но если кто-то начинает личный проект или хочет изучить Vue, конечно, Vue 3 — это место для начала?

Наталья: Я бы сказала так. Кстати, кривая обучения ничем не отличается. Поскольку группа документации намеревалась использовать старые параметры синтаксиса, я не должен говорить «старый», на самом деле это текущий синтаксис. Знакомый синтаксис по умолчанию. Потому что, если вы просмотрите документацию Vue 3, вы увидите Composition API только в продвинутых темах, а путь обучения, который у вас есть с Vue 3, похож на тот, что у вас был в Vue 2. Нет ничего страшного в том, чтобы начать с более нового. версия, если вы только изучаете Vue и пытаетесь с ним поэкспериментировать, и я считаю, что это будет лучшим вложением, если мы будем говорить о карьере. Начните изучать более новую версию, потому что она будет обгонять все проекты. В конце концов, может быть, через полгода, год, даже для крупных проектов будет миграция.

Дрю: Кажется, в моей личной карьере есть настоящий талант приходить на платформы как раз в тот момент, когда они находятся в процессе большой миграции. Я имею в виду, даже когда, вы помните, Macromedia Director, еще столько же назад, Shockwave, Flash и все такое прочее. Я пришел к этому, когда они переходили на точечный синтаксис, и мне пришлось изучить оба. И вот я здесь, в последний месяц я впервые работаю над проектом в Vue, который является проектом Vue 2, и учусь по ходу дела, и с нетерпением жду всего, что появится в Vue 3. Это безусловно, интересное время для изучения чего-то по мере его миграции, но похоже, что это не так уж сложно с Vue, и как только экосистема догонит Core, мы должны быть в хорошем месте.

Наталия: О, Дрю, я просто хочу отметить то, что ты сказал об иммиграции в крупные проекты. Вы можете представить меня в 2018 году, и я присоединяюсь к GitLab. Я не был членом основной команды, в данный момент я просто участник.

Наталья: В то же самое время Эван такой: «О, мы собираемся сделать Vue 3». Все такие: «Да, круто». Весной 2019 года вы являетесь основной командой. Я имею в виду, что весь GitLab такой: «О, это мило. У нас у всех миграция, и вы знаете, кто за это отвечает?» И вы можете только представить, как это происходит, когда вы пишете документацию для Vue 3, все будут читать, а ваша собственная компания такая: «О, я хочу кое-что узнать о Vue 3, я не понимаю вашу документацию». И ты такой: «О, черт возьми, это так больно», потому что ты там разработчик и технический писатель, вроде как здесь.

Наталья: Вы находитесь в середине этого, но я должна сказать, что это действительно полезно и для фреймворка, потому что любой большой продукт, созданный с помощью фреймворка, является отличным, абсолютно отличным полем битвы, чтобы найти ошибки и вернуть их в библиотеку, чтобы экосистема. Я могу сказать, что тесты, и GitLab с открытым исходным кодом, Vue Test Utils, инструмент тестирования для Vue. Команда использовала наш тестовый код, основанный на тестах, что имеет большой смысл, верно. Потому что вы можете найти некоторые крайние случаи и так далее. Но все же, когда я думаю о миграции GitLab на Vue 3, я чувствую личную ответственность за это. Я не только занимаюсь миграцией, я лично несу ответственность за каждую найденную ошибку.

Дрю: Оглядываясь на предыдущее поколение фреймворков JavaScript, я думаю, что одним из самых успешных из них был jQuery, и я думаю, что он набрал обороты, потому что у него был очень хорошо спроектированный API. Just this concept of taking a CSS selector and using it to query the DOM in your JavaScript was something that jQuery popularized. And I think that really resonated with hardworking developers who didn't need to learn a new way to work with JavaScript. I see Vue almost being I that same sort of camp. I mentioned I was previously working with React and moved to Vue in the last few weeks, and I found that almost everything to be more intuitive in the most genuine sense, as in I can look at something unfamiliar and pretty much understand what it's doing. And if I need to do something I've not done before I can sort of guess at how it would be implemented and usually I'm right or close to it.

Drew: Is the API of Vue something that the Core Team think about very closely or has it just turned out well almost as a happy accident because of the personalities involved?

Natalia: I think, at the times of Vue 2 we had a concept. It's changed slightly but we had a concept that was called Documentation Driven Design. And it's a really great concept because if something is really hard to explain, really hard to get and really hard to write down, maybe the API is wrong there. Maybe something is not developed as it should be because non-intuitive solutions, something that is like very cryptic, and you need to put a lot of work to explain, usually is not right. The API was shaped the way that is the easiest to explain and that's why it's intuitive. If it's easy to explain, people probably will get it on themselves. That's why the older directives like v-if and v-for look very familiar for any JavaScript developer. You don't need to explain what v-if is doing because it's clear, right.

Дрю: Это действительно так.

Natalia: It's kind of insulting and same with v-else. V-if, v-else-if, v-else and that's it. And we intuitively built v-for with syntax that looks like for loop in JavaScript and same for the biggest part of the API. I think the main intention since Vue 1.x and I think Evan also stated this in his docs was to create something that you have pleasure to work with as a tool. It's all about developer experience as well and I think this is what attracted me in Vue back in time as well. I started with Vue when it was already in beta for version 2. I didn't work that much with Vue .1. I think were not that many people familiar with Vue from the first version but I was like, “It's so nice to use”. I'm just building the same stuff and it's just been a pleasure. I don't need to think about the tool, I'm thinking about what I'm going to build. And tool is not preventing me from doing this.

Natalia: And again, I need to state this next one will be totally personal opinion, not as a Vue Core Team member. I've been working with Angular from version two to version six on a commercial project and it's a great framework. There are many different terms, it has lots of abstractions, the dependency injection is amazing, TypeScript support is absolutely incredible but I constantly had the feel I am building a wall with huge heavy bricks. And I need to just make an effort to move every single brick. I mean, the wall is amazing. Bricks are still heavy and it's just hard being a developer. And after this, working with Vue is like, “Oh, it's just like a walk in the park”.

Drew: There can be a danger with software that when it's so well designed, it makes everything feel really easy, that it sort of gets branded as a toy, as not being as powerful as the things that are really complex. Do you think that's a risk with Vue, do you think it might be regarded as less serious as some of the other reactive frameworks simply because it's better designed?

Natalia: Oh, it was. It was for this reason and for a few more reasons as well. And honestly, for a good amount of time, I think I had this question, every single conference I'd been speaking at, “Would you recommend Vue for big sized project, for enterprise project, for like serious project.” And every single time I was like, “Yes, you can use it for small project, it's easy to scaffold something, you can use it for the big size project and honestly if we speak about enterprise size project, framework is the least of the issues you need to solve.

Natalia: You can take any framework on the market, be it old one, be it Amber, be it whatever else, be it Angular One and create a good and stable architecture. You can take any of the newest framework, like latest release Vue 3, Svelte, latest React and build absolutely, incredibly awful stuff. It depends on how build it and how your team is working on this, whatever you have there, how you planned all the architectural decisions because I think, none of the framework, maybe Angular a bit, is dictating an architecture. Angular kind of does this thing rest of them are like, “You're free. Build it.” And yes, also I think the issue with Vue, not an issue, but issue in minds of people and especially in minds of company management was it's not backed by a big company.

Natalia: You have an Angular and there is Google standing behind Angular. There is React and there is Facebook supporting React. There is Vue and who is the small Chinese guy, again this is like a stigma, there is a framework of one guy, what if Evan You is hit by a bus? There was an article, “What if Evan You is hit by a bus”, I swear on dev.to. I'm like, “What are they so scared” and big companies are probably like, “What if they drop support, what if they decide, maybe even he decides, if we speak about Evan, what if he decides he does not want to work on this.” And as we can see over years it's good and stable and it's developing and it's not an issue and honestly, I think when framework is completely open sourced and built with a team of people that are not engaged, that are not subjective, that are not under one big company it's actually better for the framework.

Natalia: Last year we introduced the RFC process. It's actually just a request for comments. We have an idea, we drop it, people come there and people argue there and if we create an RFC for anything, this means that it's not decided, it's not set in stone. We just have an idea and we want to hear what community thinks. I believe it's great because Vue is shaped by developers community. This is not just loud words. No, this is not a production slogan, by the community for the community, I remember we used this but it's true. It's actually shaped by community. It's not shaped for the needs of a certain company. Even for big companies, even for companies that are sponsoring Vue. They're not shaping the framework and I believe this is great.

Drew: It's quite telling when you mentioned the list of active Core Team members is 20ish people and they're all listed on the site and next to everyone it says what thy work on in the project and also where they work professionally. And just looking down the list of where people work professionally, I mean you're at GitLab and there are other people who are just independent consultants and it's not like 18 of the 20 people work at Big Corp. Everybody is just contributing from all over the place which, as you say, is a real point of strength.

Natalia: Yeah.

Drew: That there is no one big body controlling it that could, for their own business purposes, just say, “We're changing direction, we're not going to do this anymore” and pull away all that support and leave the project in a mess. It is just lots of individuals contributing and doing their best to make something good, which I think is a really strong foundation for something as important as a framework that people are building on top of.

Drew: You know I've spent the first half of this year learning React and then changing jobs and now learning Vue. Personally it feels to me like a breath of fresh air. And I really want to commend the work that you and your colleagues are doing on that. For those who are wanting to find out more about Vue, the 3.0 release or just generally about Vue, you can go to vuejs.org currently the version three specific version as we mentioned is linked to the little banner at the top. Maybe by the time you're listening to this, the site will have changed and will just be Vue, but that's also where you find the docs and in the docs is that really good migration guide that we mentioned. I've been learning all about Vue 3.0, what have you been learning about lately, Natalia?

Natalia: I've been learning about Apollo Client version three. It's funny, because if you look at versions and I've been watching both of them, they are going completely the same way. Apollo Client was 2.6 and Vue was 2.6. And Apollo promised a release for a year and they were delaying and delaying it. It was for a long time in beta then release candidate. Same was for Vue, we announced a release and then we were delaying it again and again and moved to beta a bit late and then moved to release candidate. And they released not the same time but not with a big time difference. Apollo I think was released in Summer, beginning of Summer.

Natalia: And we use Apollo as well. I use it professionally and now I kind of try to build something with Vue 3 and Apollo 3, which is not an easy task because Apollo did a good number of changes. Again, we're adjusting them at work but, for example, removing local resolvers, is like, “What do I do now? What do I do with my local queries?” If you're curious about Apollo Client version three definitely give it a try. It's interesting to see how it's evolving.

Drew: I'm definitely going to give that a try. I've used Apollo on a couple of projects and it's really great to see that pushing ahead as well. If you as a listener would like to hear more from Natalia, you can follow her on Twitter where she is N_Tepluhina and you can find collections of her articles and videos of her public speaking events, much of which is about Vue on her website, nataliatepluhina.com

Drew: Thanks for joining us today, Natalia. Do you have any parting words for us?

Natalia: Not really, but thank you for having me, it was a lot of fun to speak there.