¿Renderizado Nativo de Frameworks Sin Duplicación de Código?

Sí, hoy quiero hablarles sobre un experimento que estamos realizando dentro de Agigrid, pensando en cómo podemos renderizar en cada uno de estos frameworks React, Angular, Vue, tal vez podamos agregar algunos más, incluyendo JavaScript, por supuesto, sin duplicar mucho de nuestro código.

Así que a veces la lógica que todos vamos a escribir, especialmente para los productos que tenemos como Agigrid, Charts y Studio, es demasiado compleja para vivir en un componente en sí mismo. Así que una vez que llegas a ese punto, necesitas empezar a pensar en una escala más grande, cómo estructuramos nuestra base de código para asegurarnos de que escale y que realmente podamos escribir este código de una manera limpia y comprobable.

Así que una de las primeras cosas a las que podrías recurrir es el enfoque MVC. Así que tienes tu modelo para tus datos, tienes tu controlador, que contiene mucho de la lógica, como qué filas deberían renderizarse cuando estamos haciendo desplazamiento virtualizado. Eso realmente no vive en un controlador, perdón, un componente en sí mismo. Es más como el motor de datos real detrás de la cuadrícula. Y luego tienes tu vista. Así que realmente todavía necesitamos renderizar esto en el DOM, y esa es la parte que realmente luego comienza a interactuar con los frameworks que soportamos. Pero la pregunta se convierte en, bueno, ¿qué realmente necesita vivir en esa vista? Porque si nuestras vistas son complicadas, eso significa que vamos a tener que duplicar bastante del trabajo para soportar JavaScript, para Angular, para React y Vue, y cualquier otro framework que queramos soportar en el futuro.

Entonces, el experimento que estamos haciendo es ¿hasta dónde podemos llevar esto? Así que si miramos el código de la vista, podríamos estar pensando, bueno, está bien, ¿realmente necesitamos lógica de eventos en la vista misma? Y la respuesta es, bueno, no, no la necesitamos. Podemos hacer esto a través de JavaScript. ¿Necesitamos el estado en los componentes? Nuevamente, no, realmente no. Podemos gestionar esto dentro de nuestro propio motor de datos de JavaScript. Así que podríamos eliminar eso también. Y luego miramos un componente de React, podemos ver este árbol anidado de componentes, y piensas, eso está definido en el componente, pero ¿es realmente crítico que esto esté en la vista? Todos estamos muy familiarizados con las estructuras de árbol. Así que eso mismo podría ser extraído. Y luego seguimos, y llegamos a este nivel donde es un elemento con un valor dentro de él. Y es como, bueno, en realidad, no podemos ir más allá. Esto es lo más bajo que podemos llegar, y esto sí necesita estar en la vista. Pero si toda esa lógica de vista se ha colapsado, ha sido extraída de la vista, y es solo el contenido del DOM, es más probable que en realidad solo estemos trabajando con una API del DOM aquí. Y cada framework es experto en renderizar al DOM. Así que en este punto, hemos extraído toda la lógica, en nuestros controladores y en nuestra lógica de JavaScript, y luego vamos a delegar el renderizado a cada uno de los frameworks.

Así que aquí es donde podemos idear esta interfaz muy precisa, que se parece un poco al DOM. Y es esta cosa de, bueno, ¿tengo hijos? ¿Están cambiando? ¿O solo estoy tratando de mostrar algo yo mismo? Y luego lo que podrías obtener es algo que se ve así. No voy a intentar centrarme en las implementaciones específicas, porque todavía está evolucionando, y probablemente no es, ya sabes, código que todos querríamos estar escribiendo. Pero la idea simple es que en realidad, en lugar de definir todos los diferentes elementos, digamos, como una tabla o una fila o una celda dentro de esa fila, podemos tener este componente genérico, que sabe cómo renderizarse a sí mismo, y luego recorrer recursivamente sus hijos. Y en su lugar, nuestros componentes, podemos definir en este nuevo, tipo de, lenguaje compartido, para decir, bueno, este es el tipo de elemento que quieres, el div, el span, y cuáles son tus hijos. Y una vez que has hecho eso, puedes tener un renderizador de DOM, puedes tener un renderizador de React, y ambos pueden trabajar en estos mismos componentes. Y así la idea es que el componente no sabe y no debería preocuparse por qué framework está realmente renderizándolo. Solo quiere ser renderizado al DOM. Así que este es el experimento que estamos realizando dentro de Agic Grid en este momento, porque queremos ver hasta dónde podemos llevar esto. Si seguimos este enfoque, en lugar de tener implementaciones escritas a mano para los diferentes frameworks, ¿podemos colapsar todo eso en una sola cosa para que podamos movernos más rápido, enviar más rápido? Pero tenemos que asegurarnos de que el rendimiento no se vea afectado. Aún puedes renderizar tus componentes personalizados de React dentro de la cuadrícula, pero se ve prometedor, y estamos emocionados por hacia dónde va esto.

Pero creo que... Oh, sí, ahí vamos. Así que se trata de escribir la lógica una vez y renderizarla de manera nativa. Pero tal vez la mejor conclusión para todos aquí no sean estos detalles específicos. Sino esta nueva idea de pensar que hacer estas iteraciones, hacer estos experimentos, se ha vuelto mucho más barato. Probablemente todos hemos tenido estas ideas sobre, bueno, creo que esta área de mi aplicación o esta parte de mi código podría necesitar algunas mejoras. Pero no tenemos el tiempo, tal vez, para experimentar completamente y trabajar a través de todos los efectos secundarios de eso. Así que aquí es donde creo que realmente podemos aprovechar la IA. Podemos lanzar nuestras ideas y dejar que haga el trabajo pesado por nosotros. Así que les animaría a todos, exploren libremente, pregunten qué pasaría si puede hacer esto, y finalmente, manténganse curiosos. Gracias. Gracias. Gracias. Gracias. Gracias.