Smashing Podcast Episode 26 z Natalią Tepluhina: Co nowego w Vue 3.0?

W tym odcinku podcastu mówimy wszystko o VueJS. Co nowego w wydaniu 3.0 i jak trudna będzie migracja? Drew McLellan rozmawia z główną członkinią zespołu, Natalią Tepluhiną, aby się tego dowiedzieć.

Pokaż notatki

• VueJS
• Przewodnik po migracji do Vue 3
• Natalia na Twitterze
• Osobisty webste Natalii

Cotygodniowa aktualizacja

• Różne sposoby projektowania cyfrowych stron produktów
  napisane przez Suzanne Scacca
• Testowanie jednostkowe w natywnych aplikacjach React
  napisany przez Fortune Ikechi
• 5 sposobów, w jakie Google Analytics pomaga programistom internetowym w projektowaniu UI/UX
  napisany przez Clarę Buenconsejo
• Zrozumienie generyków TypeScript
  napisany przez Jamiego Corkhill
• Jak używać ruchu twarzy do interakcji z typografią
  napisany przez Edoardo Cavazzę

Transkrypcja

Drew McLellan: Jest zapalonym programistą stron internetowych, ekspertem Google Developer oraz prelegentem i autorem konferencji. Obecnie pracuje jako Staff Front Engineer w GitLab, ale być może znasz ją najlepiej jako członka Vue JS Core Team. Tak wyraźnie, że zna się na Vue lepiej niż ktokolwiek inny. Ale czy wiesz, że kiedyś nauczyła kangura śpiewać. Moi Smashingowi przyjaciele, witajcie Natalię Tepluhinę.

Drew: Cześć Natalia, jak się masz?

Natalia Tepluhina: Cześć Drew, to była naprawdę fajna próba wpisania mojego nazwiska. Muszę ci przyznać kredyty. To była jedna z najlepszych rzeczy, jakie kiedykolwiek słyszałem od anglojęzycznych osób, gdy próbowali wymówić moje nazwisko. Myślę, że to niemożliwe, jeśli nie mówisz po rosyjsku. Prawidłowa wymowa to Tepluhina, ale to tak, dlatego zwykle proszę ludzi, żeby nazywali mnie Natalią i na tym poprzestańmy.

Drew: Dobra, postarałem się. Ale ważne pytanie brzmi: Smashing?

Natalia: Oczywiście, że tak.

Drew: To dobrze. Chciałem więc dziś z Wami porozmawiać o naprawdę ekscytujących wiadomościach, które mamy we wrześniu wraz z wydaniem Vue 3.0. To było ważne wydanie pod względem numeru wersji, ale naprawdę jest to duże wydanie dla Vue i było w toku od dłuższego czasu, nieprawdaż?

Natalia: Jest. Wydaje mi się, że po raz pierwszy ogłosiliśmy wersję trzecią w 2018 roku. Myślę, że została ogłoszona wiosną, a prawdziwe prace rozpoczęły się, mam na myśli to, że pomysły były na wiosnę, prawdziwe prace rozpoczęły się jesienią 2018 roku. I myślę, że zostało to oficjalnie ogłoszone na konferencji w Londynie, która odbyła się w październiku 2018 r. Aktywna praca trwała dwa lata. A jeśli się zastanowić, to dużo, poprzednia wersja została wydana w 2016 roku. A więc połowa z tych czterech lat była poświęcona również pracy Vue 3.

Drew: Jaki był rodzaj czynnika motywacyjnego przy podejmowaniu decyzji, że potrzebna jest nowa wersja główna? Czy była to rodzaj świadomej decyzji, że, w porządku, pracujemy nad główną wersją, nad Vue 3, czy też była to po prostu nagromadzenie zmian, które po prostu wymagały podniesienia wersji?

Natalia: Nie, myślę, że to był pomysł na stworzenie nowej wersji ze względu na kilka bardzo ważnych rzeczy. Więc przede wszystkim pojawiła się motywacja do zmiany reaktywności. Poprzednia była oparta na Object.defineProperty. I miał kilka zastrzeżeń, wszystkie są udokumentowane, ale nadal. Wiesz, nawet jeśli udokumentujesz coś, czego ludzie nie powinni robić, i tak to zrobią. I musiałbyś wskazać im dokumentację. Nawiasem mówiąc, nikt nie czyta dokumentacji. Z jakiegoś powodu tak się po prostu dzieje. Dopóki nie wskażesz ludziom, że nie istnieje w dokumentach. Ale dobra. I tak cię nauczymy. Więc reaktywność była jedną z rzeczy.

Natalia: Performance był następny. Vue 2 nadal miał i nie ma najgorszej wydajności, ale mieliśmy kilka pomysłów na przyspieszenie Vue. A także był jeden problem dla określonej części naszej, powiedzmy publiczności, ludzi, którzy używają Vue. To był TypeScript. Vue 2 został wewnętrznie napisany we Flow, który wciąż jest mocno napisany, ale pisanie za pomocą TypeScript było prawdziwym koszmarem, zwłaszcza jeśli pracujesz z naszym zarządzaniem stanem Vuex. To znowu była ogromna część. Ostatnim z nich było to, że w pewnym sensie przegapiliśmy funkcjonalność abstrakcyjnej logiki, nie pod względem komponentów, ale możliwych do złożenia części logicznych. Podobnie jak pomocnicy funkcji i tak dalej, ale powinny również uwzględniać aktywność widzów. Dobrym przykładem mogą być React Hooki, które pozwalają wyabstrahować części funkcjonalności, czego wyraźnie brakowało w Vue. I wiem, że teraz brzmi to tak: „Ukradłeś funkcję z React”. W rzeczywistości nie. Uważam, że zapylenie krzyżowe pomysłów jest dużą i przyjemną częścią naszego ekosystemu, a także pomaga programistom przełączać się między ulubionymi, prawda?

Natalia: Pracowaliśmy więc nad tymi głównymi funkcjami, aby stworzyć Vue 3 jako główną wersję.

Drew: Myślę, że jedną z największych zalet istnienia w ekosystemie open source jest to, że istnieje bogactwo pomysłów i doświadczeń z różnych projektów, a także możliwość pożyczania tych pomysłów i doświadczenia od innych projekty są naprawdę korzystne i wzmacniają wszystko, prawda?

Natalia: Jest. Myślę, że to działa tak, jak nazywamy wartość iteracji w GitLab. Kiedy wpadniesz na pomysł, nigdy nie jest idealny. To głównie jak bardzo surowa, bardzo mocno zakodowana rzecz. Może coś zmienić, ale to zdecydowanie nie idealne. Potrzebujesz kilku iteracji nad tym pomysłem, aby był naprawdę dobry, nawet nie doskonały, po prostu dobry. I dzieje się z pomysłami w ekosystemie. Ktoś wpada na dobry pomysł, a ty po prostu go przyjmujesz i ulepszasz. I założę się, że dobrze, będzie coś, co zaczerpnie kilka pomysłów z Vue, może już zabrali kilka pomysłów z Vue i poprawią, a tu nie ma nic złego.

Natalia: Zdecydowanie jestem przeciwna typu „kradniesz pomysły”. To nie jest kradzież, to tylko zapylenie krzyżowe.

Drew: Dokładnie tak. Wspomniałeś, że migracja do TypeScript, więc sam Vue 3 jest teraz napisany przy użyciu TypeScript, czy to prawda?

Natalia: Tak, tak. I zaufaj mi, Drew, pisałem dokumentację, mały dokument o tym, jak używać Vue z TypeScript. I pomyślałem, ok, prawdopodobnie jakoś jak Vue 2. I tak bardzo skomplikowałem dokument, że miałem ochotę wszystko wpisać wprost. Wygląda dobrze, wszystko jest wpisane. Widzę typy, więc mój ts-link jest szczęśliwy, jak dotąd tak dobry. A potem jeden z naszych programistów, który pracował z TypeScript, „Nie musisz tego robić”. Jak jak, jak? „Nie musisz robić jawnych typów danych. Po prostu podajesz mu wartość początkową, a ts-link zna jego numer. Jest już wpisany. Jak to możliwe? „Usunąłem z dokumentu 90% typów wulgarnych. Są tylko dwie rzeczy, które naprawdę musisz wpisać, to proxy komponentu, a obliczone właściwości będą miały. Nadal wymagają typów zwrotów. Ale reszta to tak, jakby wpisywano automatycznie, po prostu napisz komponent za pomocą metody, którą nazywamy define component. I to wszystko. Jest napisany.

Natalia: To było jak, to po prostu działa. A dla mnie, a dużo pracowałem z Angularem w moim poprzednim doświadczeniu, mam syndrom sztokholmski dla TypeScript. Wszystko powinno być wpisane wprost. Mam na myśli, że jeśli masz złożone typy, oczywiście będziesz musiał napisać interfejsy, ale tak działa TypeScript. Mimo to o wiele łatwiej jest teraz pracować z TypeScript dzięki Vue 3.

Drew: To świetnie, więc jest to korzyść zarówno dla projektu Vue Core Project, jak i dla programistów, którzy tworzą aplikacje przy użyciu Vue, ponieważ mogą teraz ładnie używać TypeScript w swoich aplikacjach z Vue, gdzie nie mogliby z 2.0, no cóż z każdą wersją 2.0 tak łatwo. Ci, którzy są zaznajomieni ze społecznością Vue, wiedzą, że twórca Vue, Evan You, nadal bardzo aktywnie prowadzi projekt. Jak funkcjonuje zespół podstawowy? Jaka jest jego struktura, jeśli chodzi o proces rozwoju? To nie wszystko, co Evan?

Natalia: To takie świetne pytanie Drew, bo przez lata, dosłownie, ludzie mówili o Vue tak jak, cytuję to i zabrzmię szorstko, ale przepraszam, to jest jak „szkielet jednego Chińczyka, nawet taki chiński” . I mam na myśli, że nawet w przypadku Vue 1.X istniał już zespół, za Vue 2 stał duży zespół, a za Vue 3 był jeszcze większy. Rzecz w tym, że wszyscy mamy różne obowiązki, gdy mówimy o Vue.

Natalia: Są ludzie, którzy pracują nad Core i nie jest to tylko sam Evan, on zdecydowanie wykonuje większość pracy nad Vue Core, a także kieruje projektem. Ale są ludzie, którzy pracują w Vue Core, a ich wkład jest absolutnie nieoceniony. Do zespołu Vue dołączyło też kilka nowych osób, które pracują w Core. I są też mniejsze zespoły pracujące nad ekosystemem, są ludzie, którzy pracują nad Pure Router, jak Eduardo, są ludzie pracujący nad Vue CLI, nad Vuex, też nad dokumentacją.

Natalia: Nad dokumentacją pracuje cały zespół, bo wierzymy, że dokumentacja jest ważna. A obecnie na naszej stronie jest chyba 21, 20 lub 21 osób, które zawsze nie trafiają do zespołu Core, ale to nie jest lista statyczna. Ponieważ my, oczywiście, nie zatrudniamy, jesteśmy zespołem open source, to nie jest płatna praca. Wierzymy jednak, że jeśli ktoś wnosi duży wkład do którejkolwiek części ekosystemu Vue, kiedy ludzie już wykonują pracę członka zespołu Core, to po prostu daje im uznanie dzięki dostępowi do repozytoriów i oficjalnego tytułu.

Drew: To świetnie, ponieważ jest to przypadek, w którym wkład w projekt open source może naprawdę się zwrócić. Zdobywają uznanie, co może mieć wpływ na Twoją karierę zawodową i to, co Ty.

Drew: Dla słuchaczy, którzy mogą nie być przyzwyczajeni do Vue, ale być może są zaznajomieni z innymi reaktywnymi frameworkami, takimi jak React, Angular i tak dalej. Jakie są duże, nagłówkowe zmiany w Vue 3, a konkretnie, jakie problemy starają się rozwiązać? Wspomniałeś wcześniej o składzie jako o jednej z tych rzeczy, czy to jedna z największych zmian?

Natalia: Tak, to jest jedna z największych zmian i jest to właściwie jedna z rzeczy, które są przede wszystkim takie, jak pozwól, że wygłoszę tutaj jasne oświadczenie. Skład API jest czysto addytywny. Nie chodzi o to, że musisz przepisać swoje komponenty, możesz dodać do nich TypeScript. A może wolisz używać całej składni, teraz nazywamy ją API opcji i nic się dla Ciebie nie zmieni w tych warunkach. To tak, że kiedy mówimy o nowym API, nie jest to przełomowa zmiana. Chcę to tylko podkreślić, naprawdę ważne jest, aby to powiedzieć, ponieważ kiedy po raz pierwszy ogłoszono interfejs Composition API, był to okropny moment.

Natalia: Myślę, że nie opisaliśmy ładnie zmian i sprawiliśmy, że wygląda na to, że standardową kompilacją będzie Composition API. To całkowicie nasza wina i opcje były takie, że może odrzucimy to w przyszłych kompilacjach, a nie w Vue 3, wyraźnie. A jeśli są jakiekolwiek szanse, że ludzie przeczytają to, co powiedziałeś źle, źle to przeczytają.

Natalia: Zaraz po tym oświadczeniu właśnie zaproponowaliśmy zmianę w RFC, Reddit eksplodował. Reddit był pełen takich jak: „O mój Boże. Muszę wszystko napisać. O mój Boże. Vue to nowy Angular. Zniszczą wszystko. Był też facet, który napisał artykuł na dev.to zatytułowany „Vue's Darkest Day”. Szczerze mówiąc, to był najczarniejszy dzień. Tak się czuliśmy, ale próbowałem walczyć z tym na swoim własnym Twitterze: „Ludzie, którymi tak naprawdę nie jesteśmy… Mówili, że zaczęliśmy zmieniać RFC, myślę, że Evan zaczął zmieniać RFC bez ogłaszania zmian. Więc powiedział: „Po prostu szybko to przepiszę. Wepchnijmy się w mistrza”. Ludzie szaleli na ten temat. Ponieważ kłócili się o pewne punkty, po prostu odśwież stronę i te punkty już nie istnieją. Masz wrażenie, czy jestem głupcem, czy po prostu… Co do diabła? To znaczy, to było właśnie tam. Pamiętam to. I wierzę, że nasza strategia komunikacji mogłaby być lepsza, a to nie my.

Natalia: W tej chwili za każdym razem, gdy mówię o składzie, to jest czysto addytywny, ludzie. To tylko fajna funkcja. Możesz go używać, nie możesz go używać, nie jesteś do tego zobowiązany. Po prostu… istnieje.

Drew: Jaki jest rodzaj problemu, w który ktoś może się wpakować, gdzie API kompozycji jest nową rzeczą, która pomaga mu wyjść z tego problemu? Jaki problem rozwiązuje?

Natalia: Wyobraź sobie komponent, który ma w sobie kilka funkcji. Powiedzmy, że to wyszukiwanie i sortowanie. Powiedzmy, że szukamy określonej listy i próbujemy ją posortować. To już są dwie różne funkcje, a rzecz z komponentami Vue polega na tym, że są one podzielone na podstawie opcji, a nie na podstawie logiki. Wyobraź sobie, że Twoje wyszukiwanie prawdopodobnie zawiera zapytanie, ponieważ musisz wprowadzić zapytanie do wyszukiwania i tablicy wyników. A to są dwie reaktywne właściwości. Jeśli chodzi o twój komponent, umieszczasz je w opcji zwanej danymi. I oczywiście potrzebujesz jakiejś metody do wykonania tego sortowania. Może kliknięcie przycisku, może coś innego, coś, co uruchamia wyszukiwanie. Ty tworzysz metodę. A do sortowania musisz zbudować coś w oparciu o opcje sortowania, kolejną reaktywną właściwość. Następnie wykonujesz obliczenia, aby posortować wyniki.

Natalia: W Vue do tego masz również obliczone właściwości, co jest inną opcją. W końcu Twój komponent stał się naprawdę rozdrobniony. I wyobraź sobie, że jestem programistą i mam zadanie pracować tylko nad wyszukiwaniem części. Nie mogę teraz podzielić komponentu, ponieważ te dwie cechy są na swój sposób skrzyżowane. Szukam niektórych wyników i sortuję je. I muszę skakać od danych do metody, od metody do obliczonej i na koniec naprawdę ciężko jest po prostu zmienić kontekst. Zwłaszcza, jeśli składnik rozrośnie się naprawdę duży.

Natalia: Jakie opcje mieliśmy w Vue 2.0? Pierwsza opcja nazywała się mixins, a mixin to po prostu obiekt, który może zawierać te same właściwości, co komponent i mieszamy je z komponentem. Brzmi nieźle, mogę po prostu przenieść tam wszystkie moje poszukiwania i w czym problem? Jest parę. Po pierwsze, jest to całkowicie nieelastyczne. Jeśli chcę wyszukać określony punkt końcowy i przeniosę go do mixinu, będzie to jedyny punkt końcowy, którego mogę szukać. Domieszki nie przyjmują parametrów. Stworzyłem mixin, jest całkowicie statyczny. Drugą kwestią jest to, że mixin jest wmieszany, co oznacza, że ​​dla niektórych właściwości odbywa się to jak scalenie. Na przykład, jeśli utworzyłeś hooki, zostaną one połączone. Cała logika w haczyku cyklu życia ze składnika mixin jest scalana. Ale jeśli masz właściwość danych, zimne zapytanie w domieszce i przypadkiem masz to samo w komponencie, komponent ma priorytet. To zostanie zastąpione. Nie będziesz mieć żadnych ostrzeżeń. Absolutnie. To się po prostu stanie i nie będziesz miał pojęcia, że ​​to się stało.

Drew: Cały zakres jest całkowicie pomieszany?

Natalia: Tak, całkowicie. Nie ma szans, że zobaczysz, a także mixiny są bardzo niejasnym źródłem. Po prostu importujesz mixin o nazwie i umieszczasz go, aby wyświetlić mixin właściwości komponentu, to wszystko. To bardzo ukryte i mówię o tym z punktu widzenia własnego doświadczenia. W GitLab mamy logikę, w której komponent zawiera dwa mixiny, a każdy z tych dwóch mixinów zawiera inny mixin. I oto jest właściwość, którą musisz sprawdzić, a nie ma jej w komponencie. Przejdźmy głębiej, miksowanie pierwszego poziomu. Ten go nie zawiera i ten też go nie zawiera. Gdzie to jest? Nurkujesz głęboko, tylko głębiej w króliczej nory, tylko po to, aby znaleźć tę nieruchomość, a testowanie również staje się koszmarem.

Natalia: Mixiny to bardzo, że tak powiem, głupie sposoby wydobywania logiki. To proste, jasne, bardzo łatwe do zdobycia. To sprawia tyle problemów, jeśli chcesz pracować z tym na poziomie zaawansowanym. Kolejnym sposobem abstrahowania logiki w Vue 2.0 były komponenty bez renderowania. W Vue komponent może zawierać gniazdo. Zasadniczo kawałek, w którym możesz umieścić cokolwiek z komponentu nadrzędnego. Małe okienko, właściwie szczelina. I jest pomysł na szczeliny z lunetami. Wyobraź sobie, że składnik podrzędny, który może ujawnić swój własny zakres z powrotem do elementu nadrzędnego, a zawartość sekcji będzie miała do tego dostęp. Wyobraź sobie, że mam komponent z gniazdem i komponent wykonuje całą logikę dotyczącą wyszukiwania, powiedzmy, że wyszukiwanie ma punkt końcowy z przeszłymi parametrami. Nasz komponent potomny, taki jak wyszukiwanie, a następnie udostępnia tę część swojego zakresu z powrotem do rodzica. To są wyniki wyszukiwania. Cieszyć się. Brzmi dobrze. Brzmi zdecydowanie lepiej niż mixiny. Możemy przetestować parametry. Logika jest tutaj wyraźna, zwracamy coś. Zagadnienia? Jest parę.

Natalia: Przede wszystkim stworzyłeś swoją instancję komponentu. Nie jest to najtańsza operacja na świecie. Druga część to runtime. Komponent działa tylko w czasie wykonywania, a to oznacza, że ​​wyeksponowana właściwość z tego komponentu będzie dostępna tylko w gnieździe, w którym została ona uwidoczniona jako zakres przedziałów, więc wyniki wyszukiwania są dostępne tylko w niewielkiej części szablonu. Jeśli chcesz pobawić się dyskretną częścią komponentu, nie masz tam dostępu. To czas pracy. Nie było do działania tej logiki, jeśli potrzebujesz stanu reaktywnego gdzie indziej. Oczywiście może stworzyć pomocnik jak czystą funkcję i zwrócić wyniki, ale co zrobić, jeśli muszę operować na właściwościach reaktywnych? Tak powstało Composition API. Dzięki interfejsowi Composition API możesz mieć samodzielny stan reaktywny. Stan reaktywny nie jest już tylko częścią komponentu. Możesz sprawić, że dowolny obiekt lub prymitywny będzie reaktywny. I możesz ujawnić to rodzicom, jest to bardzo wyraźne.

Natalia: Każda nieruchomość, którą chcesz zwrócić rodzicowi, jest odsłonięta. To jest jednoznaczne, możesz na to kliknąć, możesz zobaczyć, gdzie to jest, co to jest i tak dalej. A najlepsze jest to, że jeśli dołączysz część interfejsu Composition API do starego dobrego komponentu, który ma metody danych, właściwości komputera, cokolwiek, to po prostu działa. Po prostu działa idealnie, po prostu dodajesz kilka reaktywnych właściwości i metod do swojego komponentu i możesz ich używać również ze starym API opcji.

Drew: Wygląda na to, że to naprawdę pomoże programistom oczyścić podstawy kodu, jeśli chodzi o bardzo złożone komponenty lub nawet lekko złożone kombinacje komponentów. Wspomniałeś o testowalności mixinów i innych rzeczy, czy Composition API pozwala na lepszą testowalność?

Natalia: Tak, na pewno ze względu na API kompozycji, jeśli wykluczymy z tego hooki cyklu życia, ponieważ możesz również uruchomić inny hook cyklu życia w komponowanym. To właściwie czysta funkcja. Masz parametry S, coś robisz, a poza hookami cyklu życia nadal występują efekty uboczne. A testowanie czystych funkcji, jak wiadomo, jest prawdopodobnie najłatwiejsze. To tylko czarna skrzynka, masz parametry S, masz coś do zwrotu.

Drew: Brzmi to bardzo kompleksowym rozwiązaniem problemu, który z pewnością doceni wiele osób tworzących bardziej złożone aplikacje za pomocą Vue. I z pewnością brzmi to jak naprawdę świetny sposób na wyeliminowanie tego rodzaju błędów, o których wiem, że mogą wkradać się za pomocą domieszek, gdzie bardzo łatwo jest wprowadzić błędy, jak wspomniałeś, przy scalaniu zakresu i innych tego typu rzeczach.

Drew: Zawsze uważam, że przy wyborze budowania na podstawie frameworka dużą wagę przywiązuje się do stabilności interfejsu API w czasie. Może stabilność nie jest właściwym słowem, ale myślę, że wielu z nas ucierpiało, budując na frameworku, a następnie przechodzi duże przeróbki i pozostawia nam aplikacje, które albo wymagają ogromnych inwestycji w migrację, albo są po prostu związane do starej wersji frameworka, który nie jest już wspierany. To okropna sytuacja. Ile snu stracę, przenosząc duży projekt z Vue 2 do Vue 3?

Natalia: Przede wszystkim powierzchnia API jest w 90% taka sama jak była. Nie mieliśmy zbyt wielu przestarzałych rzeczy lub przestarzałych filtrów, które można zastąpić przestarzałymi centrami zdarzeń. Jeśli chcesz użyć EventEmitter, musisz również zastąpić ten oparty na widoku jakąś zewnętrzną biblioteką. To są duże zmiany, ale mówiąc o migracji… Powiem jasno, jestem teraz naprawdę rozdarty, bo z jednej strony jestem członkiem Vue JS Core Team. Z drugiej strony jestem inżynierem sztabowym w dużym projekcie, który korzysta z Vue. Jeśli masz zamiar rozpocząć migrację właśnie teraz, nie polecam tego robić. Przede wszystkim ekosystem nie jest wypuszczony, to znaczy, jeśli mówimy o podstawowych bibliotekach, takich jak Pure Router, PUX, Vue CLI, są one w dobrym stanie, ale nadal są kandydatami do wydania, a nie wydaniami. A jeśli mówimy o innych ekosystemach, takich jak może nie podstawowe biblioteki, biblioteki komponentów UI, może jakieś biblioteki do walidacji, nie są one gotowe, głównie na Vue 3. A jeśli masz duży projekt, masz tak wiele zależności, których potrzebujesz opieka. Więc to będzie skomplikowana sprawa.

Natalia: Jakie są opcje? Masz duży projekt i chcesz wykorzystać wszystkie zalety interfejsu Composition API. Jak to osiągnąć? Przede wszystkim planujemy wydanie kompilacji LTS Vue 2.0, Vue 2.7. Będzie to zawierało wiele ostrzeżeń o deprecjacji, dzięki czemu będziesz mógł zobaczyć, co będzie przestarzałe, jak to zrefaktoryzować, aby nie zepsuć tego za pomocą Vue 3. Więc nadal będziesz technicznie używać Vue 2, ale będziesz przygotowywać Vue 3 w każdym razie, ponieważ masz wszystkie ostrzeżenia.

Natalia: Po drugie, użyjemy narzędzia do migracji, które będzie mogło je po prostu uruchomić i będzie działać jako codemod, zastępując rzeczy związane z Vue 2 alternatywami dla Vue 3. Oczywiście żaden kodmod nie jest doskonały. Naszym celem jest przede wszystkim dokonywanie zamienników, gdy tylko jest to możliwe, ale także wyświetlanie ostrzeżeń, gdy niełatwo jest sobie z tym poradzić. Codemod będzie w stanie rozpoznać coś i rzucić ostrzeżenie, ale sam go nie zastąpi. To jest jak wielki plan i do momentu wydania Vue 2.7 i myślę, że w tej chwili ich szacowany czas przybycia to grudzień, jeśli dobrze pamiętam, musiałbym sprawdzić mapę drogową, ale myślę, że jest grudzień.

Natalia: Ekosystem też będzie mniej więcej gotowy. Jeśli masz duży projekt z Vue 2.0, poczekaj jeszcze trochę, aż Core się ustabilizuje, ponieważ nawet jeśli stworzysz idealną bibliotekę, nadal potrzebuje trochę czasu, aby się ustabilizować, ponieważ ludzie zaczynają używać tego, ludzie zaczynają zgłaszać błędy. Jeśli masz zamiar używać go do projektów domowych i zgłaszać błędy, bardzo serdecznie zapraszamy. A potem będzie dobry, płynny sposób migracji do Vue 3.

Drew: Narzędzie do migracji, o którym wspomniałeś, brzmi całkiem interesująco. Czy jest to w zasadzie narzędzie do analizy statycznej, które przegląda twój kod i…

Natalia: Tak, tak, tak, to kod lub narzędzie. W tej chwili jest dostępny w bardzo ograniczonym zakresie. Jest dostępny jako wtyczka Vue CLI. Jeśli masz projekt oparty na Vue CLI, możesz uruchomić aktualizację Vue i zobaczyć, jak działa narzędzie. Nie jest w takiej formie, w jakiej chcielibyśmy, aby była do tej pory. Niestety nie pracuję nad projektem zbudowanym w Vue CLI. Musiałbym poczekać i sprawdzić, co się dzieje, ale np. GitHub zrobiliśmy już kilka kroków nawet bez narzędzia do migracji do przygotowania, bo wiemy, co jest przestarzałe. W rzeczywistości jest to opisane w dokumentacji Vue 3.

Natalia: Jest przewodnik po migracji. Możesz zobaczyć wszystkie przełomowe zmiany i rzeczy, które są przestarzałe i możesz już pracować nad częścią z nich nawet na bazie kodu Vue 2.0. Na przykład w Vue 2.6 zmieniliśmy składnię dla slotów. Składnia przedziałów zakresu została przestarzała, ale nie została odrzucona, nadal istnieje. Daje ostrzeżenie, ale możesz go uruchomić. I oczywiście, z bazą kodu, która miała siedem lat, nikt nie dba o zastępowanie całej przestarzałej składni, jeśli po prostu działa. W produkcji nie ma ostrzeżeń. Automaty działają. W fazie rozwoju, np. „Och, widzę ostrzeżenie w konsoli. Może z 20, dobrze. Jest żółty, a nie czerwony. Nie obchodzi mnie to".

Natalia: Wiesz, że to zdarza się każdemu. Stworzyliśmy ogromną epopeję, aby nad tym pracować. Znajdź wszystkie aktualne zestawy starej składni. Dokładamy wszelkich starań, aby zastąpić nasze EventEmitters, ponownie, siedmioletni projekt, nie oceniaj nas. Mamy emitery zdarzeń. GitLab pracował nad EventHubs. Zamieniliśmy zabawę opartą na Vue na zewnętrzne biblioteki. Polecam zrobić to samo. Przejrzyj przewodnik po migracji, sprawdzając, co już można wymienić i jakie zmiany możesz już wprowadzić, aby się przygotować i zacząć nad tym pracować.

Drew: Przy obecnym stanie narzędzia migracji dobrym sposobem na po prostu przetestowanie wód za pomocą bazy kodu. Po prostu uruchamiam go i sprawdzam, co już oznacza, aby sprawdzić, czy wygląda dobrze, czy są jakieś duże rzeczy, czy jest jeszcze do tego niedojrzałe? Czy lepiej poczekać do grudnia, kiedy może rzeczywiście być w stanie to naprawić.

Natalia: Gdybym miała duży projekt, nie polecałabym tego robić. Jeśli masz mały, zły projekt, a może jakiś osobisty projekt, ale nie jest tak duży, polecam go uruchomić i sprawdzić problemy, takie jak wszystko, co masz, ponieważ prowadziłem dwa średniej wielkości projekty. Myślę, że jedna lub dwie kwestie. Nie mogę powiedzieć, że to niedojrzałe. Jest już w dobrym stanie. Ale znowu w przypadku dużych projektów to dziedzictwo, trochę egzotycznych rzeczy. Nie róbcie tego w produkcji, ludzie.

Natalia: Również jeśli chcesz pobawić się rusztowaniem swojego projektu, teraz Vue CLI obsługuje dwa tryby. Możesz stworzyć projekt Vue 2, możesz stworzyć projekt Vue 3. I na pewno przynajmniej spróbuj. To dobry sposób również dla nas, ponieważ podczas gry odkrywasz błędy, zgłaszasz je, staramy się je naprawiać i tak dalej.

Drew: W dokumentacji i na mapie drogowej rozwoju widzę wzmiankę o kompilacji migracji. Czy to coś innego niż to, o czym rozmawialiśmy, czy też o tym mówimy?

Natalia: Nie, nie, to jest to samo. To ten sam i powinien być gotowy, ale na razie, jeśli planujesz migrację, główną ścieżką jest po prostu czytanie dokumentów i podążanie za tym, co tam jest powiedziane, ponieważ zdecydowanie staramy się, gdy nie mamy narzędzia do migracji, zespół dokumentacji poszedł do przodu i stworzyłem szczegółowy przewodnik po tym, czym jest zmiana, dlaczego została dokonana i czym właściwie jest tutaj zamiennik.

Drew: Tak, w dokumentacji jest dość obszerny przewodnik po migracji jako część dokumentacji Vue 3 i wspomina o bardzo wielu zmianach, które wymagają migracji. Myślę, że niektóre z nich nie wpłyną na każdy projekt. Wiele z nich było w istocie skrajnymi przypadkami dla wielu ludzi. Czy to w porządku?

Natalia: Tak, spora część z nich, na przykład filtry, na pewno są przypadkiem krawędziowym, ponieważ nawet w GitLabie z, po raz trzeci, siedmioletnim kodem i dużym. Mieliśmy jedno lub dwa wystąpienia filtrów i nie były już używane. To dobrze, że szukaliśmy ich i całkowicie je usunęliśmy, ponieważ na przykład „Och, nieużywany kod” i znowu, kogo to obchodzi, że po prostu istnieje.

Natalia: Powiedziałabym, że totalnie przełomowe zmiany to zmiany modelu. Spójrz na to, ponieważ każdy projekt, który znam, na pewno zawiera przynajmniej jeden model Vue. Należy to sprawdzić i być może zmienią się również atrybuty, ponieważ obecnie uwzględniamy klasę i styl, tubulary i etery. A jeśli kiedykolwiek pracowałeś z Vue, wcześniej nie było to uwzględnione. W tej chwili sposób, w jaki przekazujesz klasę i styl komponentom potomnym, jest nieco inny i zdecydowanie warto na nie zwrócić uwagę.

Drew: Dobrze wiedzieć. W wydaniach 3.0, które zostały wydane z Vue, mam na myśli, że wspomniałeś o ekosystemie i wszystkim wokół niego, Vuex i wszystkich innych częściach ekosystemu, które muszą przejść do tego poziomu. Czy to dlatego obecnie strona internetowa, duży przycisk „Pierwsze kroki” nadal trafia do Vue 2? Wydaje się, że Vue 3 został wydany, ale nie z pełnym zaufaniem. Ale czy nadal tak jest z powodu problemu z ekosystemem?

Natalia: Nie, myślę, że właśnie znalazłeś błąd, pozwól, że szybko sprawdzę. Nie, początek wskazuje na Vue 3, jest w porządku. Mam na myśli, że jeśli wejdziesz na vuejs.org, wskazuje to na wersję drugą. Jest to celowe, ponieważ planowaliśmy zastąpić ją subdomeną, taką jak Vue 2, nad którą prace trwają, ale na razie decydujemy się zostawić vuejs.org tam, gdzie jest i stworzyć Vue 3 i dlatego na vuejs jest baner. org. Jeśli pójdziesz do jakiegokolwiek doktora-

Drew: Na górze jest bardzo mały baner, tak.

Natalia: Tak, jak mały.

Drew: Tak.

Natalia: Chyba powinniśmy to powiększyć. Większy i z lepszym kontrastem kolorów. Moje uczucia dostępności pozostają takie: „Och, nie ma tam nic kontrastowego”.

Drew: To dobra wiadomość. Jeśli ktoś zaczyna, może nie duży projekt, ale jeśli ktoś zaczyna swój osobisty projekt lub chce nauczyć się Vue, z pewnością Vue 3 jest miejscem, od którego należy zacząć?

Natalia: Tak bym powiedziała. Nawiasem mówiąc, krzywa uczenia się nie różni się aż tak bardzo. Ponieważ intencją zespołu zajmującego się dokumentacją było posiadanie starych opcji składni, nie powinienem mówić, że stare, to właściwie aktualna składnia. Znajoma składnia jako domyślna. Ponieważ jeśli przejrzysz dokumentację Vue 3, zobaczysz interfejs Composition API tylko w zaawansowanych tematach, a ścieżka szkoleniowa, którą masz z Vue 3, jest trochę podobna do tej, którą miałeś w Vue 2. Nie ma nic wielkiego, aby zacząć od nowszego wersję, jeśli dopiero uczysz się Vue i próbujesz z nią eksperymentować i uważam, że byłaby to lepsza inwestycja, jeśli mówimy o karierze. Zacznij uczyć się nowszej wersji, ponieważ wyprzedzi ona wszystkie projekty. W końcu może za pół roku, rok, nawet w przypadku dużych projektów nastąpi migracja.

Drew: Wydaje mi się, że mam w swojej osobistej karierze prawdziwy talent do wchodzenia na platformy właśnie wtedy, gdy są one w trakcie wielkiej migracji. Mam na myśli nawet tak daleko wstecz, jak pamiętasz, dyrektor Macromedia, cofanie się tak daleko i Shockwave, Flash i tego typu rzeczy. Doszedłem do tego, gdy przechodzili do składni z kropkami i musiałem nauczyć się obu. I oto jestem, w ostatnim miesiącu po raz pierwszy pracuję nad projektem w Vue, który jest projektem Vue 2, uczę się na bieżąco i nie mogę się doczekać wszystkich rzeczy, które pojawią się w Vue 3. z pewnością jest to interesujący czas, aby uczyć się czegoś podczas migracji, ale wydaje się, że z Vue nie jest to zbyt trudne, a gdy ekosystem dogoni Core, powinniśmy być w dobrym miejscu.

Natalia: Och, Drew, chcę tylko zwrócić uwagę na to, co powiedziałeś o imigracji do dużych projektów. Możesz mnie sobie wyobrazić w 2018 roku i dołączam do GitLab. Nie byłem członkiem Core Teamu, w tej chwili jestem tylko współpracownikiem.

Natalia: Zaraz w tym samym czasie Evan mówi: „Och, zrobimy Vue 3”. Wszyscy lubią „Tak, fajnie”. Wiosną 2019 roku jesteście głównym zespołem. Chodzi mi o to, że cały GitLab jest jak: „Och, to jest urocze. Wszyscy mamy migrację i wiesz, kto jest za to odpowiedzialny? I możesz sobie tylko wyobrazić, jak to się dzieje, kiedy piszesz dokumentację dla Vue 3, wszyscy będą czytać, a twoja własna firma mówi: „Och, chcę się czegoś nauczyć o Vue 3, nie rozumiem twoich dokumentów”. Więc myślisz: „Cholera, to takie bolesne”, ponieważ jesteś tam programistą i pisarzem technicznym, trochę tutaj.

Natalia: Jesteś w środku tego, ale muszę powiedzieć, że jest to bardzo korzystne również dla frameworka, ponieważ każdy duży produkt stworzony za pomocą frameworka to świetne, absolutnie wspaniałe pole bitwy, aby znaleźć błędy i przywrócić je do biblioteki, aby ekosystem. Mogę powiedzieć, że testy, a GitLab jest open source, Vue Test Utils, który jest narzędziem testowym dla Vue. Zespół używał naszego kodu testowego opartego na testach, co ma sens. Ponieważ możesz znaleźć kilka skrajnych przypadków i tak dalej. Ale mimo to, kiedy myślę o migracji GitLab do Vue 3, czuję się za to osobista odpowiedzialność. Nie tylko jestem w trakcie migracji, jestem osobiście odpowiedzialny za każdy znaleziony błąd.

Drew: Patrząc wstecz na poprzednią generację frameworków JavaScript, myślę, że jednym z najbardziej udanych z nich był jQuery w tamtych czasach i myślę, że zyskał na popularności, ponieważ miał bardzo dobrze zaprojektowany interfejs 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.

Drew: Naprawdę.

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.