Un tipo para un propósito
Cada tipo de visualization responde una clase específica de pregunta. Elegir el tipo correcto no es sobre estética — es sobre hacer la respuesta legible a primera vista. Cada tipo tiene su propia página de referencia profunda abajo; cada página enumera exactamente qué campos mapping.* y chart.* lee el renderer, el comportamiento de cross-filter, ejemplos trabajados y errores comunes.
Todas las visualizations comparten los mismos campos top-level (id, title, query, type, filters, format, published). La configuración por tipo vive en mapping más exactamente uno de: un bloque chart (para tipos basados en ECharts) o un bloque type-específico (kpi, grid, matrix) para los tipos basados en DOM.
Tipos soportados
Nueve renderers están expuestos detrás del campo type:. Dos tienen aliases (kpi/number → mismo renderer; grid/table → mismo renderer).
kpi— métrica única con delta y comparación opcionales. Alias:number.bar— comparación categórica; soporta stacking, dual-axis, orientación horizontal.line— series de tiempo; soporta dual axis y multi-series.pie— composición part-of-whole; soporta variantes donut y rose.scatter— correlación de dos measures; un punto por fila.heatmap— grid de intensidad bidimensional con scale de color explícita.funnel— stages de conversión o pipeline con drop-off.grid— tabla de datos row-level; soporta paginación, columnas congeladas, celdas compuestas. Alias:table.report_matrix— reporte jerárquico con filas agrupadas, totales y PDF export.
Cualquier otra cosa pasada como type: no está soportada y se rechaza en tiempo de validación.
El bloque chart es tipado y cerrado
Para tipos basados en ECharts (bar, line, pie, scatter, heatmap, funnel) el bloque chart es una superficie chica y tipada. Tres categorías de propiedades viven adentro:
- Shortcuts de Looky — keys únicas que colapsan múltiples decisiones coordinadas en una sola decisión (ej.
chart.stack: percent,chart.variant: donut,chart.show_value_labels). - Campos pass-through — escalares o arrays espejados a una opción subyacente específica (ej.
chart.center,chart.symbol_size,chart.gap). - Bloques pass-through — objetos anidados con un set curado snake_case de propiedades (ej.
chart.legend,chart.tooltip,chart.x_axis,chart.y_axis,chart.value_label,chart.label,chart.visual_map).
Cualquier propiedad no listada en la página de referencia por tipo se rechaza en tiempo de validación. No hay escape hatch para opciones raw de la chart library.
Los tipos basados en DOM usan su propio bloque
kpi, grid y report_matrix no están construidos sobre una chart library, así que no tienen un bloque chart en absoluto. En su lugar usan un bloque top-level type-específico — kpi, grid, matrix — más bloques auxiliares (pagination para grid y report_matrix, comparison para kpi).
Dónde buscar cada tópico
- Qué campos acepta cada viz type — la página de referencia por tipo arriba.
- Cómo se cablean los filtros — Filters.
- Comportamiento de cross-filter — Cross-filtering.
- Qué sintaxis de Malloy entiende el engine — Soporte de Malloy.
- Cómo los dashboards componen visualizations — Dashboards.
- Divergencias de adapter — Diferencias entre adapters de source.
Referencia de format strings (compartida por cada tipo)
El formato de número es field-keyed en todos los tipos de viz. Los patterns por field ganan sobre patterns de slot; los patterns de slot ganan sobre el pattern root. La gramática de patterns:
$#0,0a— currency abreviada: $1.2M, $340K$#0,00— currency completa con dos decimales: $1,234.56#0— entero: 1234#.##0,0— número con un decimal: 1,234.5#0,00%— porcentaje con dos decimales: 12.34%#.##0,00%— porcentaje con más precisión: 12.345%EUR#0— prefix de código de currency: EUR1234#0a— compacto: 1.2K, 340K, 1.2M#0b— bytes: 1.2KB, 340MB, 1.2GB
Si no hay format pattern seteado para un field, la plataforma cae a un format decimal default con dos dígitos de fracción.