3 min to read
Codeando en Angular!
Hola amigos! les dejo mi opinion y algunas soluciones para encarar algunos casos reales mientras codeamos, espero les sirva!
A medida que vamos codeando y agregando apps/projects en un repo, vemos que la app empieza a crecer y nuestros components son consumidos y reutilizados cada vez más, de forma rápida, con ningún ajuste o muy pocos ajustes.
Ahora, no todo es rosa y a veces nos encontramos con componentes que necesitamos reutilizar, quizás sin cambios visuales pero si necesitamos que consuman los datos que queremos para renderizarse.
Ahí quiero que nos enfoquemos, cuando pensamos, de donde tomamos esos datosss?? whereee? Viene Axl con su sabia respuesta
Bien, por lo general el componente existe porque ya está siendo renderizado, por lo tanto ya está consumiendo datos. Nos encontramos que por lo general el componente consume datos de un servicio e incluso nos encontramos que hay datos que….
Dos puntos:
Muchas veces vamos a tener contenidos que son fijos y que no vienen de ningun servicio, pero esto no significa que debamos poner todas las oraciones y párrafos directamente en el template, porque ahora cuando necesitamos reutilizar el componente debemos hacer más ajustes de los necesarios para poder utilizar el componente como corresponde.
Lo correcto sería que tengamos objetos y/o constantes en nuestros TS, y el template simplemente consuma y renderice.
- De donde consumimos los datos??? Me encontré con casos en donde el componente ya estaba conectado a un servicio y los datos lógicamente eran renderizados en base a eso. Ahora, nosotros queremos reutilizar ese componente pero venimos de otro componente y de otros servicios.
Hay varias alternativas, quizás la primera sea, bueno, que el componente tenga inyectado N servicios y consuma los datos de ellos dinámicamente.
Eso es una opción, pero como no sabemos cuanto más va a crecer el componente y cuánto va a ser reutilizado N veces por N componentes, mejor no inyectemos N servicios.
Para un caso de padre-hijo, usemos @Inputs! 
De esa manera, el componente va a renderizar datos del servicio principal que tiene inyectado, y en caso de que esté siendo reutilizado, renderizará en base a un modelo @input.
Así, tenemos nuestro componente que siempre va a mostrar datos en base al servicio (como estaba implementado inicialmente antes de que necesitemos reutilizarlo) ó bien, de un @input que le pasaremos desde N componentes.
Si no es caso de padre-hijo, welcome to hell. No mentira. O si. O no. O si.
Bueno si es ese el caso, podríamos hacer un “shared” service, lo mas simple y generico posible, donde solo tenga propiedades y metodos que necesitemos para este componente.
Entaooo nuestro componente ya nos queda listo, y usaría datos del servicio main ó del shared service.
Recordemos implementarlo de la manera más abstracta posible para que cuando vuelvan a reutilzar el componente, podamos continuar usando este servicio y no le agreguen N properties y N metodos cada vez que se necesite.
