Sustituye la Vista actual por los componentes principales de la interfaz del editor

¡Hola! La estructura actualmente utilizada de grapesjs se basa en aprovechar backbonejs concept de vista modelo para implementar el Virtual Dom dentro del ecosistema de grapesjs. Virtual Dom es una gran práctica que tiene una amplia gama de aplicaciones y beneficios; Pero la desventaja del dom virtual es la actual brecha entre el dom virtual y el dom real itself, lo que esto significa que el uso del dom virtual es una especie de sacrificio de rendimiento para lograr el concepto de vista modelo, que es la arquitectura ya establecida de grapesjs, react, vue, etc. Basándonos en la naturaleza en tiempo real de grapesjs y su capacidad para gestionar miles de objetos modelo según cada interacción del usuario, hay casos en los que el rendimiento se valora poco en las actualizaciones del modelo que, como resultado, no habría experiencia en tiempo real para el usuario final. como ejemplo de este escenario, piensa en llamar a addAttributes para property cambios en un componente complejo type que se invocará cada vez que el usuario final nos proporcione nuevas entradas en la sección de rasgos asociados; Cada vez que ese usuario pulsa una tecla, se notaría un retraso para que el modelo actualice los atributos del componente objetivo según la entrada del usuario. Mi propuesta sobre este asunto es eliminar el dom virtual en el saco de hiperhtml que se beneficia del dom real que está bounded a un objeto de contexto que actúa como nuestro model actual. La forma en que HyperHTML consigue el concepto de vista modelo para el dom real es aprovechando literales de plantilla nativos en JS y es associated fragmentos y interpolations. Sé que esto es un tabú muy aterrador para la implementación actual :) Pero creo que si la arquitectura de Grapesjs se ha empezado con backbone, las subpartes del ecosistema no deberían seguir el mismo camino, aunque esto es una implicación común en el camino de desarrollo de un proyecto complejo como Grapesjs; backbone puede ser muy tentador animar a los desarrolladores a seguir adelante hasta el end, pero sugiero más flexibilidad separando grapesjs en un núcleo solid con backbone y todas las demás partes aprovechando hyperhtml para introducir un ecosistema más ligero y amigable con el rendimiento, que abrace el futuro sin miedo a fallos de rendimiento. Soy un desarrollador muy ingenuo y por favor perdonadme si me equivoco con esto. hiperhtml Salud.