Ver cómo reemplazar los form e EP porque EPR parece no tenerlos

[asanzo]

• Como parte de esto hay que reemplazar el PaperInput de PBInput
• Como parte de esto tmb ver PaperGridList

[ezequielPereyra]

The journey so far...

• El primer camino que decidimos recorrer fue el de crear nuestro propio Form, junto a nuestro propio PbInput para reemplazar los de ember paper. Pero no resultó un camino tan directo como esperábamos...
  • Por default los componentes legacy de ember paper wrappean todo con un div. Para que no hagamos eso, a nuetro componente form hay que agregarle un @tagname. Eso implica que hay que escribirlo con la sintaxis de clase. O cambiar a los componentes de glimmer.
  • Como el form básico no tiene ninguna funcionalidad, tenemos que agregarla nosotros. Esto implica la posibilidad de hacer el submit o no en base a la completitud de los campos, por ejemplo. Pero para saber eso necesitamos tener las referencias a los subcomponentes desde el form. Lamentablemente ember vanilla no tiene esto, por lo que decidimos inspirarnos en lo que hacía ember paper.
  • Su estrategia es crear dos Mixines: un ParentMixin para permitir que los supercomponentes puedan suscribir subcomponentes. Y un ChildMixin, que permite a los subcomponentes suscribirse al supercomponente al momento de crearse. De esta manera, tenemos las referencias que necesitamos. Lo malo es que esto no es compatible con los nuevos componentes de glimmer, por lo que decidimos retocarlo un poco y hacer una herencia simple debido a que no teníamos la necesidad de agregar más Mixines.
  • Una cosa a tener en cuenta de esta estrategia es que, para encontrar al supercomponente, utiliza nearestOfType y está deprecado. Por lo cual, eventualmente deberíamos cambiarlo y pensar otra estrategia para poder encontrarlo.
  • Con respecto al PbInput también perdemos cierta funcionalidad que nos proveía ember paper. Como por ejemplo: las validaciones custom que se deberían hacer sobre los inputs, errores custom, etcétera. Pudimos resolver estos inconvenientes excepto uno: un posible problema de renderizado. Básicamente lo que sucedía con algunos inputs es que no mostraban ningún mensaje de error aunque el input fuera incorrecto, aún cuando el estado del componente era inválido. No te permitía hacer el submit del form, pero no te daba ninguna explicación del por qué.
  • Intentamos sin mucho éxito solucionar este problema. Como seguíamos utilizando las computed properties y es un feature que ember fue dejando de lado, decidimos probar con actualizar estos componentes a los nuevos de glimmer. Esto nos permitiría no utilizar más las computed (se reemplazan por un getter y @tracked properties) y con suerte resolvía nuestro problema de renderizado.
  • Migramos los componentes a los más actualizados, teniendo en cuenta que los nuevos componentes no wrappean todo en un div, por lo cual lo tuvimos que hacer a mano para que todo siga quedando en el lugar que corresponde. Lamentablemente, esto trajo más bugs que soluciones. Algunos inputs no permitían escritura, los errores se mostraban mal. Descubrimos que estos nuevos componentes no permiten cambiar el estado de los supercomponentes (que es lo que hacíamos antes). Es decir, el supercomponente nos pasaba una property suya y los subcomponentes se encargaban de ir modificándola en base a lo escrito en el input. En base a esto, cambiamos la asignación directa por parametrización de actions. Pero tampoco tuvo frutos...
• Como las alternativas anteriores no pintaban muy bien, decidimos explorar otra que implica integrar código React en la aplicación para poder utilizar mui . De paso podíamos ir direccionando el desarrollo a una futura migración de framework. Nos guiamos con este ejemplo.
  • Todo marchaba relativamente bien hasta que intentamos renderizar uno de los componentes de ember paper react. Aparentemente tenemos un problema de múltiples instancias de React (una de ember paper react y otra de pilas bloques). Probamos utilizando la misma versión en ambos proyectos, pero esto no solucionó el problema.
  • Esto nos llevó a una pregunta: si ya vamos a integrar React al proyecto, tiene sentido seguir con ember papar react? Entonces comenzamos a investigar qué componentes deberíamos reemplazas de esta biblioteca para poder utilizar directamente los de mui. Creo que eran como 6 componentes distintos aproximadamente, se podía llegar a hacer. Peeeeero, si integramos react, pareciera que no es posible mezclar componentes de ember con los de react. Es decir, a partir que pongamos un componente de react en la app, de ahi para abajo tienen que ser todos de react. Esto dificulta un montón poder parametrizar subcomponentes. Y este es uno de los problemas de resuelve ember paper react, y no es para nada trivial. Decidimos que este no era el camino...

Frustrados y abatidos decidimos volver a la pregunta: Queremos subir a Ember 4 para poder utilizar Tyepscript y ser un poco más felices? O acaso nos conviene resolver el creador de desafíos y finalmente empezar a migrar la app?

¿Será este el final de los guerreros Z?

[asanzo]

@ezequielPereyra

• Sobre el @tagname, también existe en el viejo ember: https://guides.emberjs.com/v3.4.0/components/customizing-a-components-element/
• Sobre el estado, se me ocurre en vez de pasar this.registerData.parentName, pasar this.registerData, y modificarle el parentName. Pero me gustaría probar, porque debería ser posible. Acá alguien hizo un form con componentes pelados de glimmer
• Y si querés volver al form de ember paper, podemos implementar nearestOfType y al joraca.

En este punto cualquier cosa que resuelva está bien, creo, Eze.

[ezequielPereyra]

@ezequielPereyra

* Sobre el `@tagname`, también existe en el viejo ember: https://guides.emberjs.com/v3.4.0/components/customizing-a-components-element/

* Sobre el estado, se me ocurre en vez de pasar `this.registerData.parentName`, pasar `this.registerData`, y modificarle el parentName. Pero me gustaría probar, porque debería ser posible. [Acá alguien hizo un form con componentes pelados de glimmer](https://www.jenweber.dev/building-an-octane-style-input/)

* Y si querés volver al form de ember paper, podemos implementar `nearestOfType` y al joraca.

En este punto cualquier cosa que resuelva está bien, creo, Eze.

• Si, eso lo sabía. Pero pensé que requería la sintaxis de clase para poder usar el decorator. Se me re pasó eso de que puede ser una property, messi.
• Voy a ir por esa. Veo si funciona.
• Por ahora dejo esa estrategia que ya está implementada.

[asanzo]

Nada de esto lo vamos a hacer pues vamos a salir de Ember.