Motor

Anatomía de un bloque nativo en Fractal-io

2026Equipo Fractal-io
Inicio/Recursos/Anatomía de un bloque nativo en Fractal-io

Cada elemento visual de una pantalla Fractal-io (un texto, una tarjeta, una lista) es un bloque. Este artículo mira de cerca cómo un bloque pasa de un nodo JSON a una vista SwiftUI real.

Un nodo del contrato

Un bloque en el contrato tiene esta forma:

      { "type": "card",
        "data": { "title": "Tu saldo", "value": "$2,430",
                   "padding": 16, "cornerRadius": 12 } }
      

El campo "type" identifica qué bloque nativo debe renderizarse; "data" trae sus propiedades.

La factory de cadena de responsabilidad

FIOCoreBlocks resuelve cada nodo con una factory de cadena de responsabilidad: una serie de manejadores, uno por bloque registrado, que se preguntan en orden si pueden renderizar ese "type", hasta que uno acepta el nodo y lo convierte en una vista nativa.

Parsing con Codable

Antes de llegar a la factory, el "data" de cada nodo se decodifica con Codable a una estructura Swift tipada específica de ese bloque. Esto da chequeo de tipos en tiempo de compilación para las propiedades del bloque, aunque el contrato en sí llegue como JSON dinámico.

Propiedades comunes a todos los bloques

Más allá de sus propiedades específicas, todo bloque comparte un set común: color de fondo, padding, margen, tamaño, alineación, forma, radio de esquina, degradado, imagen de fondo y overlays. Ese set común es lo que permite que el mismo panel de propiedades en el Composer funcione para cualquier bloque del catálogo.

Extender el registro

El registro de bloques es extensible: un equipo puede registrar un bloque propio siguiendo el mismo contrato factory + Codable, y ese bloque queda disponible para cualquier contrato que lo referencie por su "type".