---
id: "0107c"
title: "Partir modules/data_table/data_table.cpp (4777 LOC) en sub-funciones del registry"
status: pendiente
type: refactor
domain:
  - cpp-stack
  - meta
scope: module
priority: alta
depends: []
blocks:
  - "0107d"
related:
  - "0107"
  - "0081"
created: 2026-05-17
updated: 2026-05-17
tags: [modules, data-table, refactor, registry, viz]
---

# 0107c — Partir `data_table.cpp` 4777 LOC

Parte del issue principal [0107](0107-modules-standardization.md).

## Problema

`modules/data_table/data_table.cpp` es un god-file de 4777 LOC con UI entera dentro: barra de chips, tabla grid, paneles de viz, drill-down, joins, panel Ask AI, button event sink, color rules, breadcrumb, tooltips. Imposible auditar consumidores parciales. Cada bloque deberia ser una funcion del registry con su `.md` propio (Ejemplo + Cuando usarla + Gotchas).

## Decision

Partir en **6 sub-funciones** dentro de `cpp/functions/viz/` (no en `modules/data_table/` — son funciones del registry reutilizables). El modulo bundla las 6 + el entrypoint thin.

| Sub-funcion | LOC objetivo | Responsabilidad |
|---|---|---|
| `data_table_chips_cpp_viz` | ~600 | Barra de chips superior: filtros activos, TQL preview, save/load query |
| `data_table_grid_cpp_viz` | ~1200 | Render del grid: cells, sorting, freeze cols, declarative renderers (Badge/Progress/Duration/Icon/Button/Dots/CategoricalChip/ColorScale) |
| `data_table_viz_panels_cpp_viz` | ~800 | Paneles de viz lateral: histograms, line, scatter, value-counts |
| `data_table_drill_cpp_viz` | ~300 | Drill-down stack + breadcrumb |
| `data_table_ai_panel_cpp_viz` | ~500 | Panel Ask AI: prompt, llamada a `llm_anthropic`, render respuesta, export |
| `data_table_color_rules_cpp_viz` | ~400 | Editor de reglas de color por columna + aplicacion |

Entrypoint `data_table.cpp` queda ~400 LOC: compone las 6 sub-funciones, gestiona `State`, dispatcher de eventos.

## Tareas

- [ ] **3.1** Leer `data_table.cpp` end-to-end e identificar fronteras funcionales (comentario header de cada bloque sirve).
- [ ] **3.2** `cpp/functions/viz/data_table_chips.cpp` + `.h` + `.md` (NEW).
- [ ] **3.3** `cpp/functions/viz/data_table_grid.cpp` + `.h` + `.md` (NEW).
- [ ] **3.4** `cpp/functions/viz/data_table_viz_panels.cpp` + `.h` + `.md` (NEW).
- [ ] **3.5** `cpp/functions/viz/data_table_drill.cpp` + `.h` + `.md` (NEW).
- [ ] **3.6** `cpp/functions/viz/data_table_ai_panel.cpp` + `.h` + `.md` (NEW).
- [ ] **3.7** `cpp/functions/viz/data_table_color_rules.cpp` + `.h` + `.md` (NEW).
- [ ] **3.8** Reducir `data_table.cpp` a entrypoint thin que llama las 6.
- [ ] **3.9** `modules/data_table/CMakeLists.txt`: anadir las 6 sub-funciones a la static lib.
- [ ] **3.10** `modules/data_table/module.md`: bump `version: 2.0.0` (breaking interno, API publica intacta) + extender `members:` con las 6 nuevas + entrada en `## Capability growth log`.
- [ ] **3.11** Recompilar TODAS las apps que linkean `fn_module_data_table` (7 apps).
- [ ] **3.12** Smoke manual de cada app: tabla renderiza, chips funcionan, viz panels OK, AI panel OK, drill OK, color rules OK.
- [ ] **3.13** `primitives_gallery --capture` golden image antes vs despues — diff visual cero.

## Riesgos

- **State struct**: hoy `data_table::State` es opaco interno del .cpp. Tras split, las 6 sub-funciones necesitan acceder a partes de el. Opciones:
  - (a) Mover `State` a `data_table_types.h` publico (mas exposicion pero claro).
  - (b) Definir `State` en `data_table.h` con sub-structs por sub-funcion (`State::chips_state`, `State::grid_state`, etc.) y cada sub-funcion recibe su sub-state.
  - **Recomendacion**: (b). Mantiene encapsulacion y cada sub-funcion tiene firma clara.
- **API publica `data_table::render(...)` no cambia**. Es la regla dura. Si la firma debe cambiar, ya no es 0107c sino issue nuevo con migration plan.
- **Tiempo de refactor**: 4777 LOC → 6 archivos requiere cuidado quirurgico. Lanzamos `fn-constructor` en paralelo.

## Notas

- Las 6 sub-funciones son `purity: impure` (manipulan ImGui state global).
- Cada `.md` con `tags: [viz, table, imgui, ui]` + `framework: imgui`.
- El refactor lo hara un sub-agente fn-constructor lanzado en paralelo desde el flujo principal del issue 0107.