Smashing Podcast Episodio 26 con Natalia Tepluhina: ¿Qué hay de nuevo en Vue 3.0?

En este episodio de podcast, estamos hablando de VueJS. ¿Qué hay de nuevo en la versión 3.0 y qué tan difícil será migrar? Drew McLellan habla con la miembro del equipo central Natalia Tepluhina para averiguarlo.

Mostrar notas

• VueJS
• La guía de migración de Vue 3
• Natalia en Twitter
• Web personal de Natalia

Actualización semanal

• Diferentes formas de diseñar páginas de productos digitales
  escrito por Suzanne Scacca
• Pruebas unitarias en aplicaciones nativas React
  escrito por Fortuna Ikechi
• 5 formas en que Google Analytics ayuda a los desarrolladores web en el diseño de UI/UX
  escrito por Clara Buenconsejo
• Comprender los genéricos de TypeScript
  escrito por jamie corkhill
• Cómo usar Face Motion para interactuar con la tipografía
  Escrito por Edoardo Cavazza

Transcripción

Drew McLellan: es una desarrolladora web apasionada, experta en desarrolladores de Google, oradora de conferencias y autora. Actualmente, es ingeniera de personal en GitLab, pero es posible que la conozca mejor como miembro del equipo central de Vue JS. Claramente, ella conoce Vue mejor que casi nadie. Pero, ¿sabías que una vez le enseñó a cantar a un canguro? Mis amigos de Smashing, denle la bienvenida a Natalia Tepluhina.

Drew: Hola Natalia, ¿cómo estás?

Natalia Tepluhina: Hola Drew, este fue un muy buen intento de mi apellido. Necesito darte créditos. Fue una de las mejores cosas que escuché de hablantes de inglés cuando intentan pronunciar mi apellido. Supongo que no es posible si no hablas ruso. Su pronunciación correcta es Tepluhina, pero es como, es por eso que normalmente le pido a la gente que me llame Natalia y detengámonos en eso.

Drew: Está bien, bueno, hice un esfuerzo. Pero la pregunta importante es, ¿estás Smashing?

natalia: claro que lo soy

Drew: Eso es bueno. Así que quería hablarles hoy sobre algunas noticias realmente emocionantes que tenemos en septiembre con el lanzamiento de Vue 3.0. Ha sido un lanzamiento importante en términos de número de versión, pero realmente es un gran lanzamiento para Vue, y ha estado en proceso durante bastante tiempo, ¿no es así?

natalia: así es. Creo que anunciamos por primera vez la versión tres en 2018. Creo que se anunció en primavera, y el trabajo real comenzó, quiero decir, las ideas fueron en primavera, el trabajo real comenzó en otoño de 2018. Y creo que se anunció oficialmente en la Conferencia de Londres, que tuvo lugar en octubre de 2018. El trabajo activo tomó dos años. Y es mucho si lo piensas, la versión anterior se lanzó en 2016. Entonces, la mitad de estos cuatro años también se dedicaron al trabajo de Vue 3.

Drew: ¿Cuál fue el tipo de factor de motivación para decidir que se requería una nueva versión principal? ¿Fue una especie de decisión consciente de que vamos a trabajar en una versión principal, vamos a trabajar en Vue 3, o fue solo una especie de acumulación de cambios que simplemente requerían un cambio de versión?

Natalia: No, creo que fue una idea crear una nueva versión debido a algunas cosas muy importantes. Entonces, en primer lugar, había una motivación para cambiar la reactividad. El anterior se basó en Object.defineProperty. Y tenía algunas advertencias, todas están documentadas, pero aún así. Ya sabes, incluso si documentas algo que la gente no debería hacer, lo harán de todos modos. Y necesitaría señalarlos a la documentación. Por cierto, nadie lee la documentación. Por alguna razón simplemente sucede. Hasta que le indiques a la gente que no existe en los documentos, sí lo hace. Pero está bien. Te enseñaremos de todos modos. Así que la reactividad era una de las cosas.

Natalia: La actuación fue la siguiente. Vue 2 todavía tenía y no tiene el peor rendimiento, pero teníamos algunas ideas sobre cómo hacer que Vue sea más rápido. Y también hubo un punto de dolor para una parte particular de nuestra, digamos audiencia, personas que usan Vue. Era TypeScript. Vue 2 internamente se escribió en Flow, que todavía está fuertemente tipado, pero escribir con TypeScript fue una verdadera pesadilla, especialmente si está trabajando con nuestra administración estatal Vuex. Esto fue nuevamente una gran parte. Y el último fue que nos perdimos la funcionalidad de la lógica abstracta, en términos no de componentes sino de partes lógicas componibles. Como ayudantes de funciones, etc., pero también deberían poder incluir la actividad del espectador. Un buen ejemplo aquí podría ser React Hooks, ya que le permiten abstraer las partes de la funcionalidad y esto claramente faltaba en Vue. Y sé que en este momento suena como: "Le robaste la función a React". De hecho, no. Creo que la polinización cruzada de ideas es una parte importante y agradable de nuestro ecosistema y también ayuda a los desarrolladores a cambiar entre sus favoritos, ¿verdad?

Natalia: Estábamos trabajando en estas características principales para crear Vue 3 como versión principal.

Drew: Ahora creo que una de las mejores cosas de existir en un ecosistema de código abierto es que hay una gran cantidad de ideas y experiencias de todo tipo de proyectos diferentes, y la capacidad de tomar prestadas esas ideas y la experiencia de otros proyectos es realmente beneficioso y hace que todo sea más fuerte, ¿no es así?

natalia: así es. Creo que funciona de la forma en que llamamos un valor de iteración en GitLab. Cuando se te ocurre una idea, nunca es perfecta. Es principalmente como algo muy crudo, muy codificado. Tal vez cambie algo, pero definitivamente no es perfecto. Y necesita algunas iteraciones sobre esta idea para que sea realmente buena, ni siquiera perfecta, simplemente buena. Y pasa con las ideas en el ecosistema. A alguien se le ocurre una buena idea, y tú simplemente la tomas y la haces cada vez mejor. Y apuesto a que bueno, habrá algo que tomará algunas ideas de Vue, tal vez ya tomaron algunas ideas de Vue y lo mejoraron, y no hay nada malo aquí.

Natalia: Estoy totalmente en contra, como, “Estás robando ideas”. Esto no es robar, es solo polinización cruzada.

Drew: Exacto, sí. Mencionó que la migración a TypeScript, por lo que Vue 3 en sí mismo está escrito usando TypeScript ahora, ¿es correcto?

Natalia: Sí, sí lo hace. Y confía en mí, Drew, estaba escribiendo la documentación, el pequeño documento sobre cómo usar Vue con TypeScript. Y yo estaba como, está bien, probablemente de alguna manera como Vue 2. Y compliqué demasiado el documento, era como escribir todo explícitamente. Se ve bien todo está escrito. Puedo ver tipos, por lo que mi ts-link está feliz, hasta ahora todo bien. Y luego uno de nuestros desarrolladores que estaba trabajando con TypeScript, "No necesitas hacer esto". Como ¿cómo, cómo? “No es necesario hacer tipos explícitos a los datos. Solo le das un valor inicial y ts-link sabe su número. Ya está escrito. Como, ¿cómo es que? “Quité el 90 % de los tipos explícitos del documento. Solo hay dos cosas que realmente necesitará escribir: el proxy del componente y las propiedades calculadas que tendrá. Todavía requieren tipos de devolución. Pero el resto es como, escrito automáticamente, simplemente escriba un componente con un método que llamamos definir componente. Y eso es. Está mecanografiado.

Natalia: Era como, simplemente funciona. Y para mí, y estuve trabajando mucho con Angular en mi experiencia pasada, tengo el Síndrome de Estocolmo para TypeScript. Todo debe escribirse explícitamente. Quiero decir, si tiene tipos complejos, por supuesto que necesitará escribir interfaces, pero así es como funciona TypeScript. Aún así, ahora es mucho más fácil trabajar con TypeScript con Vue 3.

Drew: Eso es genial, es un beneficio tanto para Vue Core Project como para los desarrolladores que están creando aplicaciones usando Vue porque ahora pueden usar TypeScript en sus aplicaciones muy bien con Vue, donde no podían con 2.0, bueno cualquier versión. de 2.0 tan fácilmente. Aquellos que estén familiarizados con la comunidad de Vue sabrán que el creador de Vue, Evan You, todavía lidera el proyecto de manera muy activa. ¿Cómo funciona el Equipo Central? ¿Cómo se estructura cuando se trata del proceso de desarrollo? No es todo Evan, ¿verdad?

Natalia: Esa es una gran pregunta Drew, porque durante años, literalmente, la gente hablaba de Vue como, cito esto y sonaré duro, pero lo siento, es como, "Un marco de una persona china, como un marco chino incluso". . Y quiero decir, incluso con Vue 1.X, ya había un equipo y había un gran equipo detrás de Vue 2 y un equipo aún más grande detrás de Vue 3. La cuestión es que todos tenemos diferentes responsabilidades cuando hablamos de Vue.

Natalia: Hay personas que están trabajando en Core, y no es solo el propio Evan, él está haciendo la mayor parte del trabajo en Vue Core, definitivamente, y también está liderando el proyecto. Pero hay personas que trabajan en Vue Core y sus contribuciones son absolutamente invaluables. Y hay algunas personas nuevas, que también se unen al equipo de Vue, que trabajan en Core. Y también hay equipos más pequeños que trabajan en el ecosistema, hay personas que trabajan en Pure Router, como Eduardo, hay personas que trabajan en Vue CLI, en Vuex, en documentación también.

Natalia: Hay todo un equipo que trabaja en la documentación porque creemos que la documentación es importante. Y actualmente en nuestro sitio web hay, creo que 21, 20 o 21 personas, siempre se pierden la cuenta, que pertenecen al equipo central, pero esta no es una lista estática. Porque obviamente no estamos contratando, somos un equipo de código abierto, este no es un trabajo remunerado. Pero creemos que si alguien contribuye mucho a cualquiera de las partes del ecosistema de Vue, cuando las personas ya hacen el trabajo del miembro del equipo central, es solo darles reconocimiento con solo acceso a los repositorios y título formal.

Drew: Eso es genial porque es un caso en el que contribuir a un proyecto de código abierto realmente puede ser rentable para una persona. Obtienen cierto reconocimiento y eso puede tener un impacto en tu carrera profesional y lo que tengas.

Drew: Para los oyentes que pueden no estar acostumbrados a Vue pero que tal vez estén familiarizados con otros marcos reactivos, como React, Angular, etc. ¿Cuáles son los grandes cambios principales con Vue 3 y específicamente qué problemas están tratando de resolver? Mencionaste la composición antes como una de esas cosas, ¿es uno de los grandes cambios?

Natalia: Sí, este es uno de los cambios más importantes y, en realidad, es una de las cosas que, en primer lugar, quiero dejar en claro aquí. La composición API es puramente aditiva. No es que necesite reescribir sus componentes, puede agregarles TypeScript. O quizás prefiera usar toda la sintaxis, ahora lo llamamos API de opciones, y nada cambiará para usted en estos términos. Es como, cuando estamos hablando de una nueva API, este no es un cambio importante. Solo quiero enfatizar esto realmente, es muy importante decirlo porque cuando se anunció por primera vez la API de Composición fue un momento terrible.

Natalia: Creo que realmente no describimos bien los cambios e hicimos parecer que la compilación estándar será la API de composición. Es completamente nuestro mal y las opciones eran como, tal vez lo desaprobemos en futuras compilaciones, no en Vue 3, claramente. Y si hay alguna posibilidad de que la gente lea mal lo que dijiste, lo leerán mal.

Natalia: Inmediatamente después de esta declaración, fue RFC donde recién propusimos el cambio, Reddit explotó. Reddit estaba lleno de cosas como, “Oh, Dios mío. Tendré que escribir todo. Ay Dios mío. Vue es nuevo Angular. Van a romper todas las cosas”. Y había un tipo que creó un artículo en dev.to llamado Vue's Darkest Day. Fue un día muy oscuro, sinceramente. Lo sentimos, pero estaba tratando de luchar contra esto en mi propio Twitter como, "Personas que no somos realmente... Decían que comenzamos a cambiar el RFC, creo que Evan comenzó a cambiar el RFC sin anunciar cambios. Así que dijo: “Reescribiré esto rápidamente. Vamos a empujar hacia el maestro”. La gente estaba loca por esto. Debido a que estaban discutiendo sobre ciertos puntos, simplemente actualiza una página y esos puntos ya no existen. Te sientes como, soy un tonto o simplemente... ¿Qué demonios? Quiero decir, estaba justo ahí. Yo recuerdo esto. Y creo que nuestra estrategia de comunicación podría ser mejor y esto no somos nosotros.

Natalia: En este momento, cada vez que hablo de composición, esto es puramente aditivo, gente. Esta es solo una buena característica. Puede usarlo, no puede usarlo, no está obligado a hacerlo. Simplemente... existe.

Drew: ¿Cuál es el tipo de problema en el que alguien podría meterse en el que la API de composición es algo nuevo que les ayuda a salir de ese problema? ¿Qué problema está resolviendo?

Natalia: Imagina el componente que tiene algunas características dentro. Digamos que es búsqueda y clasificación. Digamos que buscamos una lista determinada y tratamos de ordenarla. Estas ya son dos características diferentes y lo que pasa con los componentes de Vue es que están divididos, según las opciones, no según la lógica. Imagine que su búsqueda probablemente tenga una consulta, porque necesita realizar una consulta para buscar una matriz de resultados. Y estas son dos propiedades reactivas. En términos de su componente, los pone en la opción que se llama datos. Y obviamente necesitas algún método para realizar la ordenación. Tal vez un clic en un botón, tal vez algo más, algo que ejecute la búsqueda. Usted crea el método. Y para clasificar necesita construir algo sobre las opciones de clasificación, otra propiedad reactiva. Luego realiza algunos cálculos para ordenar los resultados.

Natalia: En Vue, para esto también tienes propiedades computadas, que es otra opción. Al final, su componente quedó realmente fragmentado. E imagina que soy un desarrollador y tengo una tarea para trabajar solo en la parte de búsqueda. No puedo dividir el componente en este momento, porque estas dos características son un poco cruzadas en sus formas. Busco algunos resultados y los clasifico. Y necesito saltar de datos a métodos, de métodos a computados y al final es muy difícil simplemente cambiar el contexto. Especialmente si el componente crece mucho.

Natalia: ¿Qué opciones teníamos en Vue 2.0? La primera opción se llamó mixins y mixin es solo un objeto que puede contener las mismas propiedades que puede tener el componente y las estamos mezclando con un componente. Suena bien, puedo mover toda mi búsqueda allí y ¿cuál es el problema? Hay algunos. En primer lugar, esto no es completamente flexible. Si quiero buscar un cierto punto final y muevo esto a mixin, este será el único punto final que puedo buscar. Los mixins no aceptan parámetros. Creé un mixin, es completamente estático. El segundo problema es que mixin está mezclado, lo que significa que para ciertas propiedades ocurre como una fusión. Por ejemplo, si ha creado ganchos, se fusionará. Toda la lógica en el enlace del ciclo de vida del componente mixin se fusiona. Pero si tiene una propiedad de datos, una consulta fría en el mixin y por casualidad tiene lo mismo en el componente, el componente tiene prioridad. Será anulado. No tendrás advertencias. Absolutamente. Simplemente sucederá y no tendrás idea de que esto sucedió.

Drew: ¿Todo el alcance está completamente mezclado?

Natalia: Sí, completamente. No hay posibilidad de que lo veas y, además, los mixins son una fuente muy poco clara. Simplemente importe el mixin con el nombre y póngalo para ver el mixin de propiedades del componente, eso es todo. Es muy implícito y estoy hablando de esto desde el punto de vista de mi propia experiencia. Tenemos una lógica en GitLab donde un componente contiene dos mixins y cada uno de estos dos mixins contiene otro mixin. Y aquí va, aquí hay una propiedad que debe verificar y no está en el componente. Profundicemos, mixin de primer nivel. Este no lo contiene y este tampoco lo contiene. ¿Donde es? Estás sumergiéndote profundamente, solo más profundo en la madriguera del conejo, solo para encontrar esta propiedad y las pruebas también se convierten en una pesadilla.

Natalia: Los mixins son formas muy, déjame decir, tontas de extraer la lógica. Es sencillo, es claro, es muy fácil de conseguir. Te trae tantos problemas si quieres trabajar con esto en un nivel avanzado. La siguiente forma de abstraer la lógica en Vue 2.0 fueron los componentes sin procesamiento. En Vue, el componente puede contener una ranura. Básicamente, una pieza donde puedes poner cualquier cosa del componente principal. Una pequeña ventana, una ranura en realidad. Y hay una idea de las ranuras con alcance. Imagine el componente secundario que puede exponer su propio alcance al principal y el contenido de la ranura tendrá acceso a esto. Imagine que tengo un componente con una ranura y el componente realiza toda la lógica con respecto a la búsqueda, digamos una búsqueda que tiene un punto final con parámetros anteriores. Nuestro componente hijo, como buscar y luego expone esta parte de su alcance de nuevo al padre. Estos son resultados de búsqueda. Disfrutar. Suena bien. Suena definitivamente mejor que mixins. Podemos probar parámetros. La lógica es explícita aquí, estamos devolviendo algo. ¿Cuestiones? Hay algunos.

Natalia: En primer lugar, ha creado su instancia de componente. Esta no es la operación más barata del mundo. Segunda parte, es tiempo de ejecución. El componente solo funciona en tiempo de ejecución y esto significa que la propiedad expuesta de este componente solo estará disponible en el espacio en el que lo expuso como un alcance de espacios, por lo que sus resultados de búsqueda solo están disponibles en una pequeña parte de su plantilla. Si quiere jugar con la parte discreta del componente, no tiene acceso allí. Es tiempo de ejecución. No había que poner en práctica esta lógica si necesitaba un estado reactivo en otro lugar. Por supuesto, puede crear ayudante como una función pura y devolver resultados, pero ¿qué pasa si necesito operar para las propiedades reactivas? Así es como se creó la API de composición. Con la API de composición, puede tener un estado reactivo independiente. El estado reactivo ya no es solo parte del componente. Puedes hacer cualquier objeto o primitivo, reactivo. Y puede volver a exponerlo a los padres, es muy explícito.

Natalia: Cada propiedad que desea devolver a los padres está expuesta. Es explícito, puede hacer clic en esto, puede ver dónde está, qué es, etc. Y la mejor parte, si incluye la parte de la API de composición en un buen componente antiguo que tiene métodos de datos, propiedades de la computadora, lo que sea, simplemente funciona. Simplemente funciona perfectamente, solo agrega algunas propiedades y métodos reactivos a su componente y también puede usarlos con la API de opciones antiguas.

Drew: Parece que esto realmente va a ayudar a los desarrolladores a limpiar sus bases de código cuando se trata de componentes muy complejos o incluso de combinaciones de componentes levemente complejas. Y mencionó la capacidad de prueba de mixins y cosas, ¿la API de composición permite una mejor capacidad de prueba?

Natalia: Sí, definitivamente porque la API de composición, si excluimos los enlaces de ciclo de vida de esto, porque también puedes ejecutar otro enlace de ciclo de vida en el componible. En realidad es pura función. Tiene parámetros S, está haciendo algo y fuera de los ganchos del ciclo de vida todavía hay efectos secundarios. Y probar funciones puras, como saben, es probablemente lo más fácil. Es solo una caja negra, tiene parámetros S, tiene algo que devolver.

Drew: Eso suena como una solución muy completa a un problema que estoy seguro de que muchas personas que crean aplicaciones más complejas con Vue apreciarán. Y ciertamente suena como una excelente manera de eliminar el tipo de errores que sé que pueden surgir con los mixins, donde es muy fácil introducir errores, como mencionaste, con el alcance fusionado y todo ese tipo de cosas.

Drew: Siempre pienso que una consideración importante al elegir construir sobre un marco es la estabilidad de la API a lo largo del tiempo. Tal vez estabilidad no sea la palabra correcta, pero creo que a muchos de nosotros nos ha molestado construir sobre un marco, luego se somete a una gran reelaboración y nos deja con aplicaciones que requieren una inversión masiva para migrar o simplemente terminan siendo atadas. a una versión anterior de un marco que luego ya no es compatible. Es una situación horrible en la que estar. ¿Cuánto tiempo de sueño voy a perder moviendo un gran proyecto de Vue 2 a Vue 3?

Natalia: En primer lugar, la superficie de la API es un 90 % igual que antes. No teníamos tantas cosas obsoletas o filtros obsoletos que se puedan reemplazar con centros de eventos obsoletos. Si desea utilizar un EventEmitter, también deberá reemplazar una vista basada en una biblioteca externa. Estos son grandes cambios, pero hablando de migración... Permítanme dejarlo claro, estoy realmente desgarrado en este momento, porque por un lado soy miembro del equipo central de Vue JS. Por otro lado, soy un ingeniero de personal en el gran proyecto que usa Vue. Si está a punto de iniciar la migración ahora mismo, no le recomendaría hacerlo. En primer lugar, el ecosistema no se ha lanzado, es decir, si hablamos de bibliotecas principales como Pure Router, PUX, Vue CLI, están en buen estado, pero siguen siendo candidatos para el lanzamiento, no lanzamientos. Y si hablamos de otros ecosistemas, como quizás bibliotecas que no sean centrales, bibliotecas de componentes de la interfaz de usuario, quizás algunas bibliotecas de validación de formularios, no están listas, en su mayoría, para Vue 3. Y si tiene un proyecto grande, tiene tantas dependencias que necesita cuidado. Así que esto sería algo complicado.

Natalia: ¿Qué son las opciones? Tienes un gran proyecto, quieres usar todas estas bondades de la API de Composición. ¿Cómo lograr esto? En primer lugar, planeamos lanzar una compilación LTS de Vue 2.0, Vue 2.7. Eso incluirá muchas advertencias de obsolescencia, por lo que podrá ver qué quedará obsoleto, cómo refactorizarlo para no romperlo con Vue 3. Por lo tanto, técnicamente seguirá usando Vue 2 pero estará preparando Vue 3 de todos modos porque tienes todas las advertencias.

Natalia: En segundo lugar, usaremos una herramienta de migración que podrá simplemente ejecutarla y funcionará como un codemod, reemplazando las cosas relacionadas con Vue 2 con las alternativas de Vue 3. Por supuesto, ningún codemod es perfecto. Nuestro objetivo es, en primer lugar, hacer reemplazos siempre que sea posible, pero también mostrar advertencias cuando la desaprobación no sea fácil de manejar. Codemod podrá reconocer algo y lanzar una advertencia, pero no reemplazarlo por sí mismo. Esto es como un gran plan y para el momento en que se lance Vue 2.7 y creo que en este momento su tiempo estimado de llegada es diciembre, si no recuerdo mal, tendría que revisar el mapa de ruta, pero creo que es diciembre.

Natalia: El ecosistema también estará más o menos listo. Si tiene un proyecto grande con Vue 2.0, solo espere un poco más hasta que Core se estabilice porque, incluso si produce una biblioteca perfecta, aún necesita algo de tiempo para estabilizarse porque la gente comienza a usar esto, la gente comienza a informar errores. Si está a punto de usarlo para un proyecto favorito e informar errores, le invitamos a hacerlo. Y después de esto, habrá una buena forma de migrar a Vue 3 sin problemas.

Drew: Entonces, la herramienta de migración que mencionaste suena bastante interesante. ¿Es básicamente una herramienta de análisis estático que analiza su código y...

Natalia: Sí, sí, sí, es un código o una herramienta. Ahora mismo está disponible de forma muy limitada. Está disponible como complemento de Vue CLI. Si tiene un proyecto basado en Vue CLI, puede ejecutar la actualización de Vue y ver cómo funciona la herramienta. No está en la forma que queremos que esté hasta ahora. Desafortunadamente, no trabajo en un proyecto basado en Vue CLI. Tendría que esperar y verificar qué está pasando pero, por ejemplo, GitHub, ya hemos tomado algunos pasos incluso sin la herramienta de migración para prepararnos, porque sabemos qué está obsoleto. En realidad, se indica en la documentación de Vue 3.

Natalia: Hay guía de migración. Puede ver todos los cambios importantes y las cosas que han quedado obsoletas y ya puede trabajar en parte de ellos, incluso en la base de código de Vue 2.0. Por ejemplo, en Vue 2.6 cambiamos la sintaxis de las tragamonedas. La sintaxis para las ranuras de alcance quedó en desuso pero no se negó, todavía existe. Da una advertencia, pero puede ejecutarlo. Y, por supuesto, con un código base que tenía siete años, a nadie le importa reemplazar toda la sintaxis obsoleta si simplemente funciona. No hay advertencias en producción. Las tragamonedas funcionan. En desarrollo como, “Oh, veo una advertencia en la consola. Tal vez 20 de ellos, bien. Es amarillo no rojo. No me importa".

Natalia: Sabes que le pasa a todo el mundo. Creamos una gran epopeya para trabajar en esto. Encuentre todos los conjuntos actuales de sintaxis antigua. Hacemos un esfuerzo para reemplazar nuestros EventEmitters, nuevamente, un proyecto de siete años, no nos juzguen. Tenemos EventEmitters. GitLab estaba trabajando en EventHubs. Reemplazamos la diversión basada en Vue con bibliotecas externas. Recomendaría hacer lo mismo. Consulte la guía de migración para verificar qué se puede reemplazar y qué cambios ya puede hacer para prepararse y comenzar a trabajar en esto.

Drew: Con el estado actual de la herramienta de migración, es una buena manera de simplemente probar las aguas con su base de código. ¿Simplemente ejecutándolo y echando un vistazo para ver qué marca ya, para ver si se ve bien o si hay algunas cosas importantes o todavía es demasiado inmaduro para eso? ¿Es mejor esperar hasta diciembre cuando realmente podría arreglar las cosas?

Natalia: Si tuviera un proyecto grande, no lo recomendaría. Si tiene un pequeño proyecto malo o tal vez algún proyecto personal pero no es tan grande, recomendaría ejecutarlo y verificar problemas como lo que tenga porque para dos proyectos medianos lo he estado ejecutando. Creo que uno o dos problemas. No puedo decir que sea inmaduro. Ya está en buen estado. Pero para los grandes proyectos nuevamente, es un legado, es algo exótico. No hagan esto en producción, gente.

Natalia: Además, si te gustaría jugar con el andamiaje de tu proyecto, en este momento Vue CLI admite dos modos. Puede crear un proyecto Vue 2, puede crear un proyecto Vue 3. Y definitivamente pruébalo al menos. Esta es una buena manera para nosotros también porque a medida que juegas, descubres errores, informas errores, tratamos de solucionarlos, etc.

Drew: En los documentos y en la hoja de ruta de desarrollo, veo una mención de una compilación de migración. ¿Es algo diferente a lo que hemos hablado o es eso de lo que estamos hablando?

Natalia: No, no, es lo mismo. Es el mismo y debería estar listo, pero por ahora, si planea la migración, la ruta principal es simplemente leer los documentos y seguir lo que se dice allí porque definitivamente hacemos un esfuerzo cada vez que no tenemos una herramienta de migración, el equipo de documentación siguió adelante. y creó una guía detallada de cuál es el cambio, por qué se ha realizado y qué es realmente un reemplazo aquí.

Drew: Sí, en los documentos hay una guía de migración bastante completa como parte de los documentos de Vue 3 y menciona una gran cantidad de cambios que necesitan migrarse. Supongo que algunos de ellos no afectarán a todos los proyectos. Muchos de ellos eran esencialmente casos extremos para mucha gente. ¿Es eso justo?

Natalia: Sí, una buena parte de ellos, por ejemplo, los filtros, definitivamente son un caso extremo porque incluso en GitLab con, por tercera vez, una base de código de siete años y una grande. Tuvimos una o dos ocurrencias de filtros y ya no se usaron. Fue bueno que los buscáramos y los elimináramos por completo porque, como, "Oh, código sin usar" y, de nuevo, a quién le importa, simplemente existe.

Natalia: Diría que los cambios totalmente rompedores son los cambios de modelo. Eche un vistazo a esto porque cada proyecto que conozco contiene al menos un modelo Vue, seguro. Esto debe verificarse y tal vez los atributos también cambien porque actualmente estamos incluyendo clase y estilo, tubulares y éteres. Y si alguna vez trabajó con Vue, anteriormente no estaba incluido. En este momento, la forma en que pasa la clase y el estilo a los componentes secundarios es ligeramente diferente y definitivamente vale la pena prestarles atención.

Drew: Es bueno saberlo. Los lanzamientos 3.0 que vienen con Vue, quiero decir, mencionaste el ecosistema y todo lo que lo rodea, Vuex y todas estas otras partes del ecosistema que necesitan avanzar a ese nivel. ¿Es por eso que, actualmente, el sitio web, el gran botón "Comenzar" todavía va a Vue 2? Parece que Vue 3 ha sido lanzado pero no con total confianza. ¿Pero es por ese tema del ecosistema que todavía es así?

Natalia: No, creo que acabas de encontrar un error, déjame comprobarlo rápidamente. No, comenzar apunta a Vue 3, está bien. Quiero decir, si vas a vuejs.org apunta a la versión dos. Esto es intencional porque planeamos reemplazarlo con un subdominio como Vue 2, que es un trabajo en progreso, pero hasta ahora decidimos dejar vuejs.org donde está y crear Vue 3 y es por eso que hay un banner en vuejs. org. Si vas a cualquier doc-

Drew: Hay una pancarta muy pequeña en la parte superior, sí.

Natalia: Sí, como pequeña.

Drew: Sí.

Natalia: Deberíamos hacerlo más grande, supongo. Más grande y con mejor contraste de color. Mis sentimientos de accesibilidad se quedan como, "Oh, no hay nada de contraste allí".

Drew: Esas son buenas noticias. Si alguien está comenzando, tal vez no un gran proyecto, pero si alguien está comenzando un proyecto personal o quiere aprender Vue, ciertamente, ¿Vue 3 es el lugar para comenzar?

natalia: yo diría que sí. Por cierto, la curva de aprendizaje no es tan diferente. Debido a que la intención del equipo de documentación era tener las opciones de sintaxis antiguas, no debería decir antiguas, en realidad es la sintaxis actual. La sintaxis familiar como predeterminada. Porque si revisa la documentación de Vue 3, verá con la API de composición solo en temas avanzados y la ruta de aprendizaje que tiene con Vue 3 es similar a la que tenía en Vue 2. No hay gran cosa para comenzar con una más nueva. versión si acaba de aprender Vue y tratar de experimentar con él y creo que sería una mejor inversión si hablamos de carrera. Comience a aprender la versión más nueva porque superará todos los proyectos. Eventualmente, tal vez la mitad de un año, un año, incluso para proyectos de gran tamaño, habrá migración.

Drew: En mi carrera personal, parece que tengo un verdadero talento para llegar a las plataformas justo cuando están en el proceso de una gran migración. Me refiero a incluso desde, ¿te acuerdas, Macromedia Director, yendo tan atrás y Shockwave, Flash y todo ese tipo de cosas? Llegué a eso cuando estaban haciendo la transición a la sintaxis de puntos y tuve que aprender ambos. Y aquí estoy, me encuentro en el último mes, trabajando en un proyecto en Vue por primera vez, que es un proyecto de Vue 2 y aprendiendo sobre la marcha y esperando con ansias todas las cosas que vienen en Vue 3. Es Sin duda, es un momento interesante para aprender algo a medida que migra, pero parece que no es demasiado difícil con Vue y una vez que el ecosistema se haya puesto al día con el Core, deberíamos estar en un buen lugar.

Natalia: Oh, Drew, solo quiero aclarar lo que dijiste sobre los grandes proyectos de inmigración. Puedes imaginarme como en 2018 y me estoy uniendo a GitLab. No era miembro del Core Team, solo soy un colaborador en este momento.

Natalia: Inmediatamente al mismo tiempo, Evan dice: "Oh, vamos a hacer Vue 3". A todos les gusta, "Sí, genial". Primavera de 2019, eres el Core Team. Me refiero a que todo el GitLab es como, “Oh, esto es lindo. Todos tenemos migración y ¿sabes quién es el responsable de esto? Y solo puede imaginar cómo sucede cuando escribe documentación para Vue 3, todos estarán leyendo y su propia empresa dice: "Oh, quiero aprender algo sobre Vue 3, no puedo entender sus documentos". Entonces piensas, "Oh, maldita sea, esto es tan doloroso" porque eres un desarrollador allí y un escritor técnico, más o menos aquí.

Natalia: Estás en medio de esto, pero debo decir que también es realmente beneficioso para el marco porque cualquier producto grande creado con un marco es un campo de batalla excelente, absolutamente excelente para encontrar errores y devolverlos a la biblioteca, para el ecosistema Puedo decir que las pruebas, y GitLab es de código abierto, Vue Test Utils, que es una herramienta de prueba para Vue. Un equipo estaba usando nuestro código de prueba basado en pruebas, lo cual tiene mucho sentido, ¿verdad? Porque puedes encontrar algunos casos extremos, etc. Pero aún así, cuando pienso en migrar GitLab a Vue 3, siento una responsabilidad personal por esto. No solo estoy en medio de la migración, soy personalmente responsable de cada error que encontremos.

Drew: Mirando hacia atrás en la generación anterior de marcos de JavaScript, creo que uno de los más exitosos fue jQuery, en el pasado, y creo que ganó fuerza porque tenía una API muy bien diseñada. 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: Realmente lo es.

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.