egutierrez
b9716a7cd6
Snapshot de WIP acumulado de sesiones previas antes de merge wave 1 del flow 0008 (kanban_cpp + agent_runner_api + DoD schema). Incluye: - dev/flows/0008-kanban-cpp-and-agent-workflows.md - dev/issues/0112-0119*.md (7 sub-issues) - WIP previo en cmd/fn/doctor.go, registry/*, modules/, cpp/, etc. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
75 lines
4.1 KiB
Markdown
75 lines
4.1 KiB
Markdown
---
|
|
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.
|