fn_registry/dev/issues/completed/0107c-split-data-table.md

id, title, status, type, domain, scope, priority, depends, blocks, related, created, updated, tags

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

0107c — Partir data_table.cpp 4777 LOC

Parte del issue principal 0107.

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.