Smashing Podcast Episodio 26 con Natalia Tepluhina: cosa c'è di nuovo in Vue 3.0?

In questo episodio del podcast, stiamo parlando di VueJS. Cosa c'è di nuovo nella versione 3.0 e quanto sarà difficile migrare? Drew McLellan parla con Natalia Tepluhina, membro del team principale per scoprirlo.

Mostra note

• VueJS
• La guida alla migrazione di Vue 3
• Natalia su Twitter
• Il sito personale di Natalia

Aggiornamento settimanale

• Diversi modi per progettare pagine di prodotti digitali
  scritto da Suzanne Scacca
• Unit test in applicazioni native di reazione
  scritto da Fortune Ikechi
• 5 modi in cui Google Analytics aiuta gli sviluppatori Web nella progettazione dell'interfaccia utente/UX
  scritto da Clara Buenconsejo
• Comprensione dei generici TypeScript
  scritto da Jamie Corkhill
• Come utilizzare Face Motion per interagire con la tipografia
  scritto da Edoardo Cavazza

Trascrizione

Drew McLellan: È un'appassionata sviluppatrice web, un'esperta di Google Developer, nonché relatrice e autrice di conferenze. Attualmente è una Staff Front Engineer presso GitLab, ma potresti conoscerla meglio come membro del Vue JS Core Team. Quindi chiaramente lei conosce Vue meglio di quasi chiunque altro. Ma lo sapevi che una volta ha insegnato a cantare a un canguro. I miei amici Smashing, per favore, date il benvenuto a Natalia Tepluhina.

Drew: Ciao Natalia, come stai?

Natalia Tepluhina: Ciao Drew, questo è stato davvero un bel tentativo sul mio cognome. Ho bisogno di darti crediti. È stata una delle cose migliori che abbia mai sentito da persone che parlano inglese quando hanno provato a pronunciare il mio cognome. Immagino che non sia possibile se non parli russo. La sua pronuncia corretta è Tepluhina, ma è come se, ecco perché di solito chiedo alle persone di chiamarmi Natalia e fermiamoci a quello.

Drew: Va bene, ho fatto uno sforzo. Ma la domanda importante è: stai Smashing?

Natalia: Certo che lo sono.

Drew: Va bene. Quindi volevo parlarvi oggi di alcune novità davvero interessanti che avremo a settembre con il rilascio di Vue 3.0. È stata una versione importante in termini di numero di versione, ma è davvero una grande versione per Vue, ed è in lavorazione da un po' di tempo, non è il momento?

Natalia: Lo è. Penso che abbiamo annunciato per la prima volta la versione tre nel 2018. Penso che sia stata annunciata in primavera e che il vero lavoro sia iniziato, voglio dire, le idee erano in primavera, il vero lavoro è iniziato nell'autunno del 2018. E penso che sia stato annunciato ufficialmente alla Conferenza di Londra, avvenuta nell'ottobre 2018. Il lavoro attivo ha richiesto due anni. Ed è molto se ci pensi, la versione precedente è stata rilasciata nel 2016. Quindi metà di questi quattro anni sono stati dedicati anche al lavoro su Vue 3.

Drew: Qual è stato il tipo di fattore motivazionale nel decidere che fosse necessaria una nuova versione principale? È stata una sorta di decisione consapevole che, va bene, lavoreremo su una versione principale, lavoreremo su Vue 3, o era solo una sorta di accumulo di modifiche che richiedevano semplicemente un aumento della versione?

Natalia: No, penso sia stata un'idea creare una nuova versione per alcune cose molto importanti. Quindi, prima di tutto, c'era una motivazione per cambiare la reattività. Quello precedente era basato su Object.defineProperty. E aveva alcuni avvertimenti, sono tutti documentati ma comunque. Sai, anche se documenti qualcosa che le persone non dovrebbero fare, lo faranno comunque. E dovresti indicarli alla documentazione. Nessuno legge la documentazione a proposito. Per qualche motivo succede e basta. Fino a quando non indichi le persone che non esiste nei documenti, lo fa. Ma va bene. Ti insegneremo comunque. Quindi la reattività era una delle cose.

Natalia: La performance è stata la prossima. Vue 2 ha ancora avuto e non ha le peggiori prestazioni, ma avevamo alcune idee su come rendere Vue più veloce. E c'era anche un punto dolente per una parte particolare del nostro pubblico, diciamo, le persone che usano Vue. Era dattiloscritto. Vue 2 internamente è stato scritto in Flow, che è ancora fortemente tipizzato, ma digitare con TypeScript era un vero incubo soprattutto se stai lavorando con il nostro Vuex di gestione dello stato. Questa è stata di nuovo una parte enorme. E l'ultimo è stato che ci mancava la funzionalità della logica astratta, in termini non di componenti ma di parti logiche compossibili. Come funzioni di supporto e così via, ma dovrebbero essere in grado di includere anche l'attività del visualizzatore. Un bell'esempio qui potrebbe essere React Hooks, giusto che ti permettono di astrarre le parti della funzionalità e questo era chiaramente mancante in Vue. E so che in questo momento suona come "Hai rubato la funzione da React". Non in effetti. Credo che l'impollinazione incrociata delle idee sia una parte importante e interessante nel nostro ecosistema e aiuti anche gli sviluppatori a passare da un preferito all'altro, giusto?

Natalia: Quindi stavamo lavorando su queste caratteristiche principali per creare la Vue 3 come versione principale.

Drew: Ora penso che una delle grandi cose dell'esistenza in un ecosistema open source è che c'è una ricchezza di idee ed esperienze tutte là fuori da tutti i tipi di progetti diversi e la capacità di prendere in prestito quelle idee e prendere in prestito l'esperienza da altri progetti è davvero vantaggioso e rende tutto più forte, vero?

Natalia: Lo è. Penso che funzioni nel modo in cui chiamiamo un valore di iterazione in GitLab. Quando ti viene in mente un'idea, non è mai perfetta. È per lo più come una cosa molto grezza, molto codificata. Forse cambia qualcosa, ma è come se non fosse assolutamente perfetto. E hai bisogno di alcune iterazioni su questa idea per renderla davvero buona, nemmeno perfetta, semplicemente buona. E succede con le idee nell'ecosistema. Qualcuno ha una buona idea e tu la prendi e la rendi sempre migliore. E scommetto che bene, ci sarà qualcosa che prenderà alcune idee da Vue, forse hanno già preso alcune idee da Vue e lo renderanno migliore, e qui non c'è niente di male.

Natalia: Sono fortemente contraria, tipo "Stai rubando idee". Questo non è un furto, questa è solo impollinazione incrociata.

Drew: Esattamente, sì. Hai menzionato che la migrazione a TypeScript, quindi Vue 3 stesso è scritto utilizzando TypeScript ora, è corretto?

Natalia: Sì, sì, è così. E fidati, Drew, stavo scrivendo la documentazione, il piccolo documento su come usare Vue con TypeScript. E io ero tipo, ok, probabilmente in qualche modo come Vue 2. E ho complicato eccessivamente il documento, mi è sembrato di scrivere tutto in modo esplicito. Sembra buono tutto è digitato. Posso vedere i tipi, quindi il mio ts-link è felice, finora tutto bene. E poi uno dei nostri sviluppatori che stava lavorando con TypeScript, "Non è necessario farlo". Come come, come? “Non è necessario eseguire tipi espliciti sui dati. Gli dai solo un valore iniziale e ts-link conosce il suo numero. È già digitato. Tipo, come mai? “Ho rimosso il 90% dei tipi espliciti dal documento. Ci sono solo due cose che dovrai davvero digitare è il proxy del componente e le proprietà calcolate avranno. Richiedono ancora tipi di ritorno. Ma il resto è come, digitato automaticamente, basta scrivere un componente con un metodo che chiamiamo define component. E questo è tutto. È digitato.

Natalia: Era come se funzionasse. E per me, e ho lavorato molto con Angular nella mia esperienza passata, ho la sindrome di Stoccolma per TypeScript. Tutto dovrebbe essere digitato in modo esplicito. Voglio dire, se hai tipi complessi, ovviamente dovrai scrivere interfacce, ma è così che funziona TypeScript. Tuttavia, è molto più facile lavorare con TypeScript in questo momento con Vue 3.

Drew: Quindi è fantastico, quindi è un vantaggio sia per Vue Core Project, sia per gli sviluppatori che stanno creando applicazioni usando Vue perché ora possono usare TypeScript nelle loro applicazioni bene con Vue, dove non potrebbero con 2.0, beh qualsiasi versione di 2.0 così facilmente. Coloro che hanno familiarità con la community di Vue sapranno che il creatore di Vue Evan You sta ancora guidando il progetto in modo molto attivo. Come funziona il Core Team? Come è strutturato quando si tratta del processo di sviluppo? Non è tutto Evan vero?

Natalia: È un'ottima domanda, Drew, perché per anni, letteralmente, la gente ha parlato di Vue come, cito questo e suonerò duro, ma scusa, è come "Una struttura di una persona cinese, come anche la struttura cinese" . E voglio dire, anche con Vue 1.X, c'era già una squadra e c'era una grande squadra dietro Vue 2 e una squadra ancora più grande dietro Vue 3. Il fatto è che abbiamo tutti responsabilità diverse quando parliamo di Vue.

Natalia: Ci sono persone che stanno lavorando su Core, e questo non è solo Evan stesso, sta facendo la maggior parte del lavoro su Vue Core, sicuramente, e sta anche guidando il progetto. Ma ci sono persone che lavorano in Vue Core e i loro contributi sono assolutamente inestimabili. E ci sono alcune nuove persone, che si uniscono anche al team di Vue, che lavorano in Core. E ci sono anche team più piccoli che lavorano sull'ecosistema, ci sono persone che lavorano su Pure Router, come Eduardo, ci sono persone che lavorano su Vue CLI, su Vuex, anche sulla documentazione.

Natalia: C'è un intero team che lavora sulla documentazione perché crediamo che la documentazione sia importante. E attualmente sul nostro sito web ci sono, penso 21, 20 o 21 persone, che mancano sempre il conteggio, che appartengono al team Core, ma questo non è un elenco statico. Perché noi, non stiamo assumendo ovviamente, siamo un team open source, questo non è un lavoro retribuito. Ma crediamo che se qualcuno contribuisce molto a una qualsiasi delle parti dell'ecosistema Vue, quando le persone già svolgono il lavoro di membro del team Core, è solo, dando loro il riconoscimento con il solo accesso ai repository e al titolo formale.

Drew: È fantastico perché è un caso in cui contribuire a un progetto open source può davvero ripagare un individuo. Ottengono un certo riconoscimento e questo può avere un impatto sulla tua carriera professionale e su ciò che hai.

Drew: Per gli ascoltatori che potrebbero non essere abituati a Vue ma forse hanno familiarità con altri framework reattivi, come React, Angular e così via. Quali sono i grandi cambiamenti nei titoli di Vue 3 e in particolare quali problemi stanno cercando di risolvere? Hai menzionato la composizione prima come una di quelle cose, è uno dei grandi cambiamenti?

Natalia: Sì, questo è uno dei più grandi cambiamenti, ed è in realtà una delle cose che sono, prima di tutto, come lasciami fare una chiara dichiarazione qui. L'API di composizione è puramente additiva. Non è che devi riscrivere i tuoi componenti, puoi aggiungervi TypeScript. Oppure potresti preferire, utilizzare tutta la sintassi, ora la chiamiamo API delle opzioni e nulla cambierà per te in questi termini. È come se, quando parliamo di nuove API, non si tratta di un cambiamento dirompente. Voglio solo sottolineare questo davvero, è davvero importante dirlo perché quando ha annunciato per la prima volta l'API di composizione è stato un momento terribile.

Natalia: Penso che non abbiamo descritto bene le modifiche e abbiamo fatto sembrare che la build standard fosse l'API di composizione. È completamente il nostro male e le opzioni erano tipo, forse lo deprecheremo nelle build future, non in Vue 3, chiaramente. E se ci sono possibilità che le persone leggano ciò che hai detto male, lo leggeranno male.

Natalia: Subito dopo questa dichiarazione, è stato RFC a proporre il cambiamento, Reddit è esploso. Reddit era pieno di cose tipo "Oh, mio ​​dio. dovrò scrivere tutto Dio mio. Vue è il nuovo Angular. Romperanno tutte le cose". E c'era un ragazzo che ha creato un articolo su dev.to chiamato Vue's Darkest Day. Era un giorno più buio, onestamente. Ci siamo sentiti così, ma ero come provare a combattere questo sul mio stesso Twitter come: "Persone non lo siamo davvero ... Stavano dicendo che abbiamo iniziato a cambiare l'RFC, penso che Evan abbia iniziato a cambiare l'RFC senza annunciare modifiche. Quindi ha detto: "Lo riscriverò rapidamente. Mettiamoci dentro come un maestro”. La gente era pazza per questo. Poiché stavano discutendo su determinati punti, aggiorni semplicemente una pagina e quei punti non esistono più. Ti senti come se fossi uno sciocco o solo... Che diavolo? Voglio dire, era proprio lì. Mi ricordo questo. E credo che la nostra strategia di comunicazione potrebbe essere migliore e non siamo noi.

Natalia: In questo momento, ogni volta che parlo di composizione, questo è puramente additivo, gente. Questa è solo una bella caratteristica. Puoi usarlo, non puoi usarlo, non sei obbligato a farlo. Solo... Esiste.

Drew: Qual è il tipo di problema in cui qualcuno potrebbe trovarsi in cui l'API di composizione è una cosa nuova che li aiuta a uscire da quel problema? Che problema sta risolvendo?

Natalia: Immagina il componente che ha alcune caratteristiche al suo interno. Diciamo che è ricerca e ordinamento. Diciamo che cerchiamo un certo elenco e proviamo a ordinarlo. Queste sono già due caratteristiche diverse e il fatto con i componenti Vue è che sono divisi, in base alle opzioni, non in base alla logica. Immagina che la tua ricerca abbia probabilmente una query, perché devi creare una query per cercare e una matrice di risultati. E queste sono due proprietà reattive. In termini di componente, li metti nell'opzione chiamata dati. E ovviamente hai bisogno di un metodo per eseguire l'ordinamento. Forse un clic di un pulsante, forse qualcos'altro, qualcosa che esegue la ricerca. Tu crei il metodo. E per l'ordinamento è necessario creare qualcosa sulle opzioni di ordinamento, un'altra proprietà reattiva. Quindi esegui alcuni calcoli per ordinare i risultati.

Natalia: In Vue, per questo, hai anche proprietà calcolate, che è un'altra opzione. Alla fine, il tuo componente è diventato davvero frammentato. E immagina di essere uno sviluppatore e di avere un compito su cui lavorare solo sulla ricerca di parti. Non posso dividere il componente in questo momento, perché queste due caratteristiche sono un po' incrociate nei loro modi. Cerco alcuni risultati e li ordino. E ho bisogno di saltare dai dati al metodo, dal metodo al calcolato e alla fine è davvero difficile cambiare il contesto. Soprattutto se il componente diventa davvero grande.

Natalia: Quali opzioni avevamo in Vue 2.0? La prima opzione era chiamata mixins e mixin è solo un oggetto che può contenere le stesse proprietà che il componente può avere e le stiamo mescolando con un componente. Suona bene, posso semplicemente spostare tutta la mia ricerca lì e qual è il problema? Ci sono alcuni. In primo luogo, questo non è completamente flessibile. Se voglio cercare un determinato punto finale e lo sposto su mixin, questo sarà l'unico punto finale che posso cercare. I mixin non accettano parametri. Ho creato un mixin, è completamente statico. Il secondo problema è che il mixin è mescolato, il che significa che per alcune proprietà avviene come un'unione. Ad esempio, se hai creato hook, verrà unito. Tutta la logica nell'hook del ciclo di vita del componente mixin viene fusa insieme. Ma se hai una proprietà data, una query a freddo nel mixin e per caso hai lo stesso nel componente, il componente ha una priorità. Sarà ignorato. Non avrai avvisi. Assolutamente. Succederà e tu non avrai idea che sia successo.

Drew: Tutto lo scopo è completamente misto?

Natalia: Sì, completamente. Non c'è alcuna possibilità che tu possa vedere e inoltre, i mixin sono una fonte molto poco chiara. Importi semplicemente il mixin con il nome e lo metti per visualizzare il mixin delle proprietà del componente, il gioco è fatto. È molto implicito e ne parlo dal punto di vista della mia esperienza. Abbiamo una logica in GitLab in cui un componente contiene due mixin e ognuno di questi due mixin contiene un altro mixin. Ed ecco qua, ecco una proprietà che devi controllare e non è nel componente. Andiamo più a fondo, mixin di primo livello. Questo non lo contiene e anche questo non lo contiene. Dove è? Ti stai immergendo in profondità, solo più in profondità nella tana del coniglio, solo per trovare questa proprietà e anche il test diventa un incubo.

Natalia: I mixin sono modi molto, lasciami dire, stupidi per estrarre la logica. È chiaro, è chiaro, è molto facile da ottenere. Ti porta così tanti problemi se vuoi lavorare con questo a livello avanzato. Il prossimo modo di atrarre la logica in Vue 2.0 erano i componenti senza rendering. In Vue, il componente può contenere uno slot. Fondamentalmente un pezzo in cui puoi mettere qualsiasi cosa dal componente genitore. Una piccola finestra, una fessura in realtà. E c'è un'idea di slot con scope. Immagina che il componente figlio che può esporre il proprio ambito al genitore e il contenuto dello slot avrà accesso a questo. Immagina di avere un componente con uno slot e il componente esegue tutta la logica relativa alla ricerca, diciamo la ricerca che ha un punto finale con parametri passati. Il nostro componente figlio, come la ricerca, espone questa parte del suo ambito al genitore. Questi sono i risultati della ricerca. Divertiti. Suona bene. Suona decisamente meglio dei mixin. Possiamo testare i parametri. La logica qui è esplicita, stiamo restituendo qualcosa. Questioni? Ci sono alcuni.

Natalia: Prima di tutto, hai creato la tua istanza del componente. Questa non è l'operazione più economica al mondo. Seconda parte, è runtime. Il componente funziona solo in runtime e questo significa che la proprietà esposta di questo componente sarà disponibile solo nello slot in cui l'hai esposta come ambito di slot, quindi i risultati della tua ricerca sono disponibili solo nella piccola parte del tuo modello. Se vuoi giocare con la parte discreta del componente, non hai accesso lì. È tempo di esecuzione. Non c'era modo di agire in questa logica se avevi bisogno di uno stato reattivo da qualche altra parte. Ovviamente può creare helper come una funzione pura e restituire risultati, ma cosa succede se devo operare per le proprietà reattive? È così che è stata creata l'API di composizione. Con l'API di composizione puoi avere uno stato reattivo autonomo. Lo stato reattivo non è più solo una parte del componente. Puoi rendere reattivo qualsiasi oggetto o primitivo. E puoi esporlo al genitore, è molto esplicito.

Natalia: Ogni proprietà che vuoi restituire ai genitori è esposta. È esplicito, puoi cliccare su questo, puoi vedere dove si trova, cos'è e così via. E la parte migliore, se includi la parte dell'API di composizione nel vecchio componente buono che ha metodi di dati, proprietà del computer, qualunque cosa, funziona e basta. Funziona perfettamente, aggiungi solo alcune proprietà e metodi reattivi al tuo componente e puoi usarli anche con le vecchie API delle opzioni.

Drew: Sembra che aiuterà davvero gli sviluppatori a ripulire le loro basi di codice quando si tratta di componenti molto complessi o anche di combinazioni di componenti leggermente complesse. E hai menzionato la testabilità di mixin e cose, l'API di composizione consente una migliore testabilità?

Natalia: Sì, sicuramente perché Composition API, se escludiamo gli hook del ciclo di vita da questo, perché puoi anche eseguire un altro hook del ciclo di vita nel componibile. In realtà è pura funzione. Hai parametri S, stai facendo qualcosa e al di fuori degli hook del ciclo di vita ci sono ancora effetti collaterali. E testare le funzioni pure, come sai, è probabilmente la cosa più semplice. È solo una scatola nera, hai parametri S, hai qualcosa da restituire.

Drew: Sembra una soluzione molto completa a un problema che sono sicuro che molte persone che creano app più complesse con Vue apprezzeranno. E sicuramente suona come un ottimo modo per eliminare il tipo di bug che so possono insinuarsi con i mixin, dove è molto facile introdurre bug, come hai menzionato, con l'ambito che viene unito e tutto quel genere di cose.

Drew: Penso sempre che una considerazione importante quando si sceglie di costruire su un framework sia la sua stabilità dell'API nel tempo. Forse stabilità non è la parola giusta, ma penso che molti di noi siano rimasti colpiti costruendo su un framework, quindi subisce una grande rielaborazione e ci lascia con app che richiedono un investimento massiccio per la migrazione o finiscono per essere vincolate a una vecchia versione di un framework che poi non è più supportato. È una situazione orribile in cui trovarsi. Quanto sonno perderò spostando un grande progetto da Vue 2 a Vue 3?

Natalia: Innanzitutto, la superficie dell'API è per il 90% la stessa di prima. Non avevamo molte cose obsolete o filtri obsoleti che sono sostituibili con hub eventi obsoleti. Se si desidera utilizzare un EventEmitter, è necessario sostituire anche uno basato sulla visualizzazione con una libreria esterna. Questi sono grandi cambiamenti, ma parlando di migrazione... Lascia che sia chiaro, sono davvero combattuto in questo momento, perché da un lato sono un membro del Vue JS Core Team. D'altra parte, sono uno Staff Engineer nel grande progetto che utilizza Vue. Se stai per iniziare la migrazione in questo momento, non consiglierei di farlo. Prima di tutto l'ecosistema non viene rilasciato, voglio dire se parliamo di librerie core come Pure Router, PUX, Vue CLI, queste sono in buone condizioni ma sono comunque release candidate, non release. E se parliamo di altri ecosistemi come forse librerie non core, librerie di componenti dell'interfaccia utente, forse alcune librerie di convalida dei moduli, non sono pronte, principalmente, per Vue 3. E se hai un grande progetto, hai così tante dipendenze che devi cura. Quindi questa sarebbe una cosa complicata.

Natalia: Quali sono le opzioni? Hai un grande progetto, vuoi usare tutta questa bontà dell'API di composizione. Come raggiungere questo obiettivo? Prima di tutto abbiamo in programma di rilasciare una build LTS di Vue 2.0, Vue 2.7. Ciò includerà molti avvisi di deprecazione, quindi sarai in grado di vedere cosa verrà deprecato, come rifattorizzarlo per non romperlo con Vue 3. Quindi tecnicamente utilizzerai ancora Vue 2 ma preparerai Vue 3 comunque perché hai tutti gli avvisi.

Natalia: In secondo luogo, utilizzeremo uno strumento di migrazione che sarà in grado di eseguirlo e funzionerà come un codemod, sostituendo le cose relative a Vue 2 con le alternative a Vue 3. Naturalmente, nessun codemod è perfetto. Miriamo, prima di tutto, a effettuare sostituzioni quando possibile, ma anche a mostrare avvisi ogni volta che la deprecazione non è facilmente gestibile. Codemod sarà in grado di riconoscere una cosa e lanciare un avviso ma non sostituirla da sola. Questo è come un grande piano e nel momento in cui Vue 2.7 viene rilasciato e penso che in questo momento il loro tempo stimato di arrivo sia dicembre se ricordo bene, avrei bisogno di controllare la road map, ma penso che sia dicembre.

Natalia: Anche l'ecosistema sarà più o meno pronto. Se hai un grande progetto con Vue 2.0, aspetta ancora un po' fino a quando Core non si stabilizza perché anche se produci una libreria perfetta ha ancora bisogno di tempo per stabilizzarsi perché le persone iniziano a usarlo, le persone iniziano a segnalare bug. Se stai per usarlo per progetti di animali domestici e segnalare bug, per favore, sei il benvenuto a farlo. E dopo questo ci sarà un modo semplice per migrare a Vue 3.

Drew: Quindi lo strumento di migrazione che hai menzionato sembra piuttosto interessante. È fondamentalmente uno strumento di analisi statica che esamina il tuo codice e...

Natalia: Sì, sì, sì, è un codice o uno strumento. In questo momento è disponibile in un modo molto limitato. È disponibile come plug-in di Vue CLI. Se hai un progetto basato su Vue CLI, puoi eseguire l'aggiornamento di Vue e vedere come funziona lo strumento. Non è nella forma che vorremmo che fosse finora. Sfortunatamente, non lavoro su un progetto basato su Vue CLI. Avrei bisogno di aspettare e controllare cosa sta succedendo ma, ad esempio GitHub, abbiamo già fatto alcuni passaggi anche senza lo strumento di migrazione da preparare, perché sappiamo cosa è deprecato. In realtà è indicato nella documentazione di Vue 3.

Natalia: C'è una guida alla migrazione. Puoi vedere tutte le modifiche sostanziali e le cose che sono state deprecate e puoi già lavorare su una parte di esse anche sulla base di codice Vue 2.0. Ad esempio, in Vue 2.6 abbiamo cambiato la sintassi per gli slot. La sintassi per gli slot dell'ambito è stata deprecata ma non negata, esiste ancora. Dà un avviso ma puoi eseguirlo. E, naturalmente, con una base di codice di sette anni, a nessuno interessa sostituire tutta la sintassi deprecata se funziona. Non ci sono avvisi in produzione. Le slot funzionano. In fase di sviluppo tipo "Oh, vedo alcuni avvisi nella console. Forse 20 di loro, bene. È giallo non rosso. Non mi interessa”.

Natalia: Sai che succede a tutti. Abbiamo creato una grande epopea per lavorare su questo. Trova tutti i set correnti della vecchia sintassi. Facciamo uno sforzo per sostituire i nostri EventEmitters, ancora una volta, progetto di sette anni, non giudicarci. Abbiamo EventEmitter. GitLab stava lavorando su EventHubs. Abbiamo sostituito il divertimento basato su Vue con librerie esterne. Consiglierei di fare lo stesso. Consulta la guida alla migrazione controllando cosa può essere già sostituito e quali modifiche puoi già apportare per prepararti e iniziare a lavorarci.

Drew: Con lo stato attuale dello strumento di migrazione, è un buon modo per testare le acque con la tua base di codice. Basta eseguirlo e dare un'occhiata per vedere cosa segnala già, per vedere se sembra a posto o se ci sono cose importanti o è ancora troppo immaturo per quello? È meglio aspettare fino a dicembre quando potrebbe effettivamente essere in grado di sistemare le cose.

Natalia: Se avessi un grande progetto, non consiglierei di farlo. Se hai un piccolo progetto negativo o forse qualche progetto personale ma non è così grande, ti consiglio di eseguirlo e controllare problemi come qualsiasi cosa tu abbia perché per due progetti di medie dimensioni l'ho eseguito. Penso che uno o due problemi. Non posso dire che sia immaturo. È già in buone condizioni. Ma per i grandi progetti ancora, è eredità, è roba esotica. Non farlo in produzione, gente.

Natalia: Inoltre, se desideri giocare con l'impalcatura del tuo progetto, in questo momento Vue CLI supporta due modalità. Puoi creare un progetto Vue 2, puoi creare un progetto Vue 3. E sicuramente provalo almeno. Questo è un buon modo anche per noi perché mentre giochi, scopri bug, segnali bug, cerchiamo di risolverli e così via.

Drew: Nei documenti e nella roadmap di sviluppo vedo menzione di una build di migrazione. È qualcosa di diverso da quello di cui abbiamo parlato o è di questo che stiamo parlando?

Natalia: No, no, è lo stesso. È lo stesso e dovrebbe essere pronto ma per ora, se pianifichi la migrazione, il percorso principale è solo leggere i documenti e seguire tutto ciò che viene detto lì perché ci sforziamo sicuramente ogni volta che non abbiamo lo strumento di migrazione, il team di documentazione è andato avanti e ha creato una guida dettagliata di qual è il cambiamento, perché è stato fatto e cosa è effettivamente un sostituto qui.

Drew: Sì, nei documenti c'è una guida alla migrazione piuttosto completa come parte dei documenti Vue 3 e menziona un sacco di modifiche che devono essere migrate. Immagino che alcuni di questi non influiranno su ogni progetto. Molti di loro erano essenzialmente casi limite per molte persone. È giusto?

Natalia: Sì, una buona parte di essi, ad esempio i filtri, sono sicuramente dei casi limite perché anche su GitLab con, per la terza volta, una base di codice vecchia di sette anni e una grande. Abbiamo avuto una o due occorrenze di filtri e non sono stati più utilizzati. È stata una buona cosa che li abbiamo cercati e rimossi completamente perché tipo "Oh, codice inutilizzato" e ancora, chi se ne frega esiste.

Natalia: Direi che i cambiamenti radicali sono i cambiamenti del modello. Dai un'occhiata a questo perché ogni singolo progetto che conosco contiene almeno un modello Vue, di sicuro. Questo dovrebbe essere controllato e forse anche gli attributi cambiano perché attualmente stiamo includendo classe e stile, tubolari ed ether. E se hai mai lavorato con Vue, in precedenza non era incluso. In questo momento, il modo in cui si passa classe e stile a un componente figlio è leggermente diverso e meritano sicuramente un'attenzione.

Drew: Buono a sapersi. Le versioni 3.0 rilasciate con Vue, intendo dire che hai menzionato l'ecosistema e tutto ciò che lo circonda, Vuex e tutte queste altre parti dell'ecosistema che devono andare avanti a quel livello. È per questo che, attualmente, il sito Web, il grande pulsante "Guida introduttiva" va ancora tutto su Vue 2? Sembra che Vue 3 sia stato rilasciato ma non con piena fiducia. Ma è a causa del problema dell'ecosistema che è ancora così?

Natalia: No, penso che tu abbia appena trovato un bug, fammi controllare velocemente. No, iniziare punta a Vue 3, va bene. Voglio dire, se vai su vuejs.org punta alla versione due. Questo è intenzionale perché abbiamo pianificato di sostituirlo con un sottodominio come Vue 2, che è in lavorazione, ma finora abbiamo deciso di lasciare vuejs.org dov'è e creare Vue 3 ed è per questo che c'è un banner su vuejs. org. Se vai su qualsiasi documento-

Drew: C'è uno striscione molto piccolo in alto, sì.

Natalia: Sì, come piccola.

Drew: Sì.

Natalia: Dovremmo renderlo più grande, immagino. Più grande e con un migliore contrasto cromatico. I miei sentimenti di accessibilità rimangono come "Oh, non c'è niente di contrasto lì".

Drew: Questa è una buona notizia. Se qualcuno sta iniziando, forse non un grande progetto, ma se qualcuno sta iniziando un progetto personale o vuole imparare Vue, sicuramente Vue 3 è il punto di partenza?

Natalia: Direi di sì. La curva di apprendimento non è poi così diversa. Poiché era intenzione del team di documentazione avere le vecchie opzioni di sintassi, non dovrei dire vecchio, in realtà è la sintassi attuale. La sintassi familiare come predefinita. Perché se esamini la documentazione di Vue 3 vedrai con l'API di composizione solo negli argomenti avanzati e il percorso di apprendimento che hai con Vue 3 è un po' simile a quello che avevi in ​​Vue 2. Non c'è niente di grave per iniziare con un nuovo versione se stai solo imparando Vue e provi a sperimentarlo e credo che sarebbe un investimento migliore se parliamo di carriera. Inizia ad imparare la versione più recente perché supererà tutti i progetti. Alla fine, forse tra un anno e mezzo, un anno, anche per progetti di grandi dimensioni ci sarà la migrazione.

Drew: Mi sembra di avere nella mia carriera personale un vero talento nel venire sulle piattaforme proprio mentre sono nel processo di una grande migrazione. Intendo anche da lontano, ricordi, il Direttore di Macromedia, andando così indietro e Shockwave, Flash e tutto quel genere di cose. Ci sono arrivato mentre stavano passando alla sintassi del punto e ho dovuto imparare entrambi. Ed eccomi qui, mi ritrovo nell'ultimo mese, a lavorare su un progetto in Vue per la prima volta, che è un progetto Vue 2 e ad imparare mentre vado e non vedo l'ora di tutte le cose che arriveranno in Vue 3. È sicuramente un momento interessante per imparare qualcosa mentre migra, ma sembra che non sia troppo difficile con Vue e una volta che l'ecosistema ha raggiunto il Core, allora dovremmo essere a buon punto.

Natalia: Oh, Drew, voglio solo sottolineare ciò che hai detto sul grande progetto di immigrazione. Puoi immaginarmi come, nel 2018 e mi unirò a GitLab. Non ero membro del Core Team, sono solo un collaboratore in questo momento.

Natalia: Immediatamente nello stesso momento Evan dice "Oh, faremo Vue 3". A tutti piace "Sì, fantastico". Primavera del 2019 tu sei il Core Teeam. Voglio dire, l'intero GitLab è tipo "Oh, è carino. Abbiamo tutti una migrazione e sai chi è in qualche modo responsabile di questo?" E puoi solo immaginare come succede quando scrivi la documentazione per Vue 3, tutti leggeranno e la tua stessa azienda dice: "Oh, voglio imparare qualcosa su Vue 3, non riesco a capire i tuoi documenti". Quindi dici "Oh, accidenti, è così doloroso" perché lì sei uno sviluppatore e uno scrittore di tecnologia, un po' qui.

Natalia: Sei nel mezzo di questo, ma devo dire che è davvero vantaggioso anche per il framework perché qualsiasi prodotto di grandi dimensioni creato con un framework è un campo di battaglia fantastico, assolutamente fantastico per trovare i bug e riportarli alla libreria, per l'ecosistema. Posso dire che testa e GitLab è open source, Vue Test Utils, che è uno strumento di test per Vue. Un team stava usando il nostro codice di test basato sui test, il che ha molto senso, giusto. Perché puoi trovare alcuni casi limite e così via. Tuttavia, quando penso di migrare GitLab a Vue 3, mi sento una responsabilità personale per questo. Non sono solo nel mezzo della migrazione, sono personalmente responsabile di ogni singolo bug che troveremo.

Drew: Ripensando alla generazione precedente di framework JavaScript, penso che uno dei framework di maggior successo sia stato jQuery, ai tempi, e penso che abbia guadagnato terreno perché aveva un'API estremamente ben progettata. 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: Lo è davvero.

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.