#18 Es que para trabajar con el estado de los componentes, input y output no sirve de mucho. Los usarás para comunicar componentes extremadamente simples, pero si me dices que termina "siendo un lío", es que entonces estás sobreutilizado esas herramientas. Para eso están los servicios y la habilidad de inyectarlos a nivel de componente, a nivel de módulo o a nivel de app.
edit: Ahí va un ejemplo que he complicado de más para hacer ver cómo incluso en situaciones de pasar muchos datos a un componente, no tiene por qué quedar realmente mal por hacerlo por input/output (y para traspasar datos relacionados con APIs, es directamente mejor llamar al servicio pertinente).
Consideremos por un momento un componente con una plantilla bastante dinámica que admite muchas configuraciones. ¿No sería esta acaso una forma sencilla de resolver dicha cuestión?
export interface InfoOverlayData {
title: string;
properties: Array<{propName: string, value: any}>;
routing: {
url: string;
parameters: any
};
propertiesStyles?: any;
image?: any;
author?: any;
imageStyles?: any;
authorLabel?: string;
containerHeight?: number;
containerWidth?: number;
}
Se usaría tal que...:
return {
title: "Evento deportivo",
routing: entity.routing,
author: entity.get("userId"),
authorLabel: "Organizador: ",
properties: [
{
propName: "Recorrido: ",
value: distance
}
],
containerHeight: 170,
}
Pasando todos estos parámetros de configuración en un mismo objeto entendido como una interfaz de TS, te permite jugar con el componente fácil: construyes ese objeto primero (algo a lo que el propio IDE te ayudará), metiendo los parámetros obligatorios que necesitas, y dejándote espacio incluso para añadir aquellos opcionales que prefieras. Y santas pascuas.
