Mantener automáticamente miles de ejemplos de código en múltiples variaciones de frameworks

¿Puedo hacerles una pregunta antes de comenzar? ¿Cuántos de ustedes estarían contentos en su trabajo si les pidieran mantener miles de demostraciones de código? Para mí, eso sería felicidad. Probablemente haya un buen trabajo para ustedes en la redacción de documentación. Pero para mí, ya saben, eso no es lo que quiero hacer. Y esa es la situación en la que nos encontramos en aggrid.

Ahora nuestro objetivo es crear la mejor cuadrícula de datos JavaScript del mundo. Pero entendemos, como Rich mencionó antes, que nuestra cuadrícula solo será tan buena como lo que nuestros usuarios puedan hacer con ella, y la forma en que podemos mostrarles lo que pueden hacer es a través de nuestra documentación. Así que estamos decididos a tener una demostración de código en vivo para cada función que tenemos. Así podrán ver lo que hace la cuadrícula. Y también podrán ver el código que impulsa esa demostración.

Entonces, si simplemente comenzamos a agregar todos estos ejemplos para nuestras funciones, en realidad tenemos alrededor de 500 demostraciones ahora, y piensan que eso es lo suficientemente malo. Esperen hasta que se den cuenta de que AG grid es agnóstico. Así que admitimos JavaScript, TypeScript, Angular, React, pueden usar hooks y clases, pueden escribirlo en view two, view three. Y queremos que, cuando estén usando nuestra documentación, puedan ver el código en el framework que están utilizando. Así que multiplicamos todos estos números juntos, y terminamos con alrededor de 8,000 demostraciones. Así que no hay forma, incluso si quieren hacerlo, de que puedan mantener el ritmo y no cometer errores al copiar y pegar. Y honestamente, será bastante aburrido.

Entonces, en un mundo ideal, lo que queremos hacer es escribir un solo ejemplo, y lo vamos a hacer en TypeScript, porque para Angular, necesitamos tipos. Si quieren React con TSX, necesitan tipos. Para nuestro ejemplo de JavaScript, simplemente eliminamos los tipos y listo. Y luego podemos usar eso como punto de partida para nuestra vista y React con solo JavaScript puro. Ahora, el primer paso para lograr esto es categorizar su código. Aquí tenemos un ejemplo de código de AG grid. Tenemos una configuración estática. Tenemos un callback y también un evento externo. Y la razón por la que necesitamos categorizar esto es para poder aplicar convertidores específicos del framework a cada una de estas áreas específicas. Porque sabemos que Angular utiliza una sintaxis diferente a React. Y es diferente dependiendo de lo que estén tratando de lograr. Pero luego surge el desafío y la pregunta, ¿cómo categorizamos nuestro ejemplo de código de manera programática? Y ahí es donde entran en juego los árboles de sintaxis abstracta. Porque podemos representar cualquier fragmento de código como un árbol. Por ejemplo, la función resaltada aquí es sizeToFit.

Y eso se representa como una definición de función con una propiedad de nombre, parámetros y el cuerpo. Y cualquier archivo de código que tengas, puedes descomponerlo y representarlo en esta estructura de árbol.

Entonces, por ejemplo, si estás usando TypeScript para analizarlo, le das el texto fuente del ejemplo y te dará este AST. Y luego vamos a recorrer este árbol y usar coincidencias de patrones para extraer todas estas diferentes secciones. Así que encontraremos qué es una propiedad, qué es un método de instancia y qué es un controlador de eventos.

Este es un ejemplo de cómo podría verse una de estas coincidencias de patrones. Así que tenemos... ¿Es esto una llamada a función? Así que recorremos todos los nodos del árbol y si es una llamada a función, entonces lo extraemos en estos controladores de eventos externos donde tenemos el nombre, los parámetros, y el cuerpo. Así que construimos este modelo de memoria de cómo se ve realmente el ejemplo de código. Y luego usamos nuestros convertidores específicos del framework. Así que aquí podemos ver Angular y Vue. Tienes la sintaxis diferente para tratar de lograr algo similar. Y así, usamos estos convertidores específicos del framework para cada categoría. Y una vez que hayas hecho eso, puedes generar ese código en una plantilla base y encontrar que tienes tus ejemplos de Angular, React y Vue.

Y solo hemos escrito el de TypeScript junto con estos convertidores. Solo para asegurarnos de que no hemos cometido un error, lo validamos con TypeScript. Probamos cada uno de estos ejemplos con Cypress para asegurarnos de que no haya errores, un poco de captura de instantáneas para las regresiones visuales. Y si estamos muy entusiasmados y cuidadosos, podemos comparar las diferencias con git en todo el repositorio para asegurarnos de que no hemos hecho nada tonto. Y el resultado para nosotros es que podemos actualizar todos nuestros ejemplos de framework en un solo lugar. Por ejemplo, agregamos soporte para React y TypeScript, y solo tomó un día, pero hay 500 ejemplos allí. Si queremos agregar soporte para un nuevo framework, solo agregamos un convertidor. Y somos desarrolladores felices porque no estamos manteniendo todos estos ejemplos, y hay más tiempo para trabajar en características. Y creo que nuestros usuarios están más contentos porque pueden ir a nuestra documentación, decir qué framework están usando, qué variación están usando, y pueden ver el código que coincide con eso para copiar y pegar en su aplicación.

Así que como conclusiones, quiero que te des cuenta de este punto, que podemos usar árboles de sintaxis abstracta de TypeScript para generar y razonar sobre nuestro código. Y una excelente manera de comenzar con esto es astexplorer.net. Simplemente ingresa tu código allí y te mostrará cómo se ve el árbol de sintaxis abstracta. Y, finalmente, no mantengas manualmente algo que puedes generar. Si te inspiras en este trabajo, me encantaría saber qué construyes con él. Gracias.