Closed redfox-mx closed 1 month ago
jariaspe
commented
2 months ago Hola @redfox-mx,
Igual me equivoco, pero me da la sensación de que estás hablando de la versión interna de Cells. Si es así por favor haznos tu petición a través de los canales internos BBVA.
Un saludo.
redfox-mx
commented
2 months ago Hola!
Hummm si viene desde ese punto de partida en la versión interna, pero aplica para esta versión opensource.
La verdad desconozco los medio para hacer esa petición internamente, pero también es un hito que podríamos plantear aquí, y preparar open-cells para mejorar n.n y que cualquier persona pueda desarrollar con facilidad herramientas de desarrollo para cells. Esa es una de las magias de los proyectos opensource n.n
Pd: Este no es un issue como tal, si no, una petición para comentarios. Que usualmente son espacios para comentar y platicar sobre funcionalidades que podrían ser beneficiosas y estrategias que podrían ser llevadas a cabo, de tal forma que podamos platicar sin comprometer alguna entrega y aprender juntos
jariaspe
commented
2 months ago Hola,
Te lo comentaba porque para la versión interna sí existe una extensión de chrome para las devtools que ha estado funcionando varios años. Ahora depende de la configuración de tu ordenador puede que no funcione y tenemos en el roadmap publicarla en open source también para que se pueda usar en ambos mundos.
De todas formas te insisto en que los comentarios internos los hagas a través de los canales internos BBVA, puedes buscar nuestros canales de contacto en platform.
Un saludo.
El problema
Actualmente uno de los grandes problemas al desarrollar en cells es la falta de herramientas que permitan la depuración de las características propias del bridge, imposibilitando a los desarrolladores poder inspeccionar el estado (canales) y características del mismo (navegación, ciclo de vida del bridge, eventos "privados").
Para solventar este hecho muchas veces se tiene que recurrir a "hacks" sobre el bridge, dependiendo ciegamente en propiedades internas o un entendimiento mas profundo del mismo.
Esto causa que las aplicaciones desarrolladas en cells no puedan ser depuradas de la mejor manera, impidiendo su optimización y en algunos casos retrasando el desarrollo, sobre todo para las personas nuevas que empiezan trabajar con cells.
Si bien, se intento en su momento crear una devtool para cells, el proyecto fue abandonado y carece (IMO) de una falta de perspectiva centrada en la experiencia de desarrollo. Recayendo en el mismo punto anterior, realizar "hacks" o "monkey patching" para poder acceder a los datos del bridge, dejando de ser funcional para proyectos medianos/grandes.
La solucion
Implementar un modelo basado en eventos que permita proporcionar un api para la depuración del bridge, como inspeccionar su estado, canales, enlazados (bindings) templates, etc. Para esto muchos de los frameworks y librerías modernas distribuyen dos versiones del código fuente en sus paquetes, una version de producción y otra de desarrollo.
De esta forma es posible lograr que en entornos de desarrollo se pueda hacer debbugin y por lo tanto, sea mas facil, desarrollar, optimizar y depurar aplicaciones cells sin preocuparse por la carga, seguridad o el performance que estas podrían tener para los clientes finales, pues estos builds son generalmente cargados de manera automatica por la mayoria de bundlers (webpack, vite, rspack) o configurados de maneras muy simples como es en el caso de rollup, esbuild, etc.
Un buen punto de entrada puede ser la solución que se usa en lit, en donde se añaden eventos al objeto global para poder ser escuchados posteriormente por alguna devtool u otra herramienta
https://github.com/lit/lit/blob/440a44012e61dbff405d5dd0c32b9df09d9c2e14/packages/lit-html/src/lit-html.ts#L196-L209
atte: diegojesus.hernandez.gonzalez@bbva.com