Una software factory arma el mismo tipo de pantalla una y otra vez: un onboarding, un catálogo, un formulario de cotización. Cada cliente nuevo suele significar reconstruir ese patrón desde cero, dentro del código de esa app puntual. Este artículo mira qué hace falta para que, en cambio, ese componente se diseñe una vez y se reutilice.
Un template no es una app
Un template de Fractal-io es un contrato JSON: describe estructura, datos y eventos de una pantalla, nunca lógica ejecutable ni las reglas de negocio de un cliente en particular. Eso es lo que lo hace portable — el mismo template puede renderizarse en la app de un cliente distinto, siempre que su backend sepa entregar el contexto (los datos) que ese template espera.
La convención FIO/* hace el componente reconocible
El plugin de Figma reconoce un bloque por el nombre de su componente maestro: FIO/container, FIO/text y así para cada bloque del catálogo. Un frame necesita Auto Layout para exportarse. Esta convención es lo que permite que un componente armado para un cliente se identifique y se reutilice para otro, sin ambigüedad sobre qué bloque nativo le corresponde.
Qué cambia entre clientes (y qué no)
Lo que cambia entre clientes son los datos: el catálogo de un cliente no es el catálogo de otro, ni sus reglas de permisos. Eso vive en el backend de cada cliente, no en el template. Lo que no cambia es la estructura visual del bloque — el mismo Card, el mismo Grid, el mismo Text Field — y el motor que lo interpreta, FIOCoreBlocks, que es el mismo Swift Package integrado en cada app.
Qué está construido y qué es roadmap
Hoy el plugin exporta de punta a punta dos bloques (container y text) a un JSON estático y determinista. Marcar un campo como dinámico ($bind) para que el mismo template muestre datos distintos por cliente está diseñado pero todavía en desarrollo activo, así como resolver ese binding contra el backend real de cada cliente. Ambos son parte del trabajo que se prioriza durante un piloto, no algo disponible de forma general todavía.