refactor(dashboard): drop the vestigial DashboardApp.prefs field left by #586

Abierto
#595 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
typescript
Área
frontend

Línea de trabajo

Empieza en src/ui/dashboard.ts:240 y rastrea cada punto donde se construye DashboardApp, incluido el cast adyacente as ResultsApp. Comprueba si la construcción por etapas o los puntos de integración abordados por #589 y #588 siguen requiriendo prefs; después ejecuta npm test, npm run check:types y npm run check:arch para confirmar que el campo se ha eliminado o que existe una justificación actual para mantenerlo.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

inbox refactor

Surfaced while shipping #586 (phase 1 of #593). Deferred rather than folded in, because
removing it is a DashboardApp-shape change with no bearing on #586's acceptance criteria.

What

src/ui/dashboard.ts:240 declares:

prefs: Pick<AppPreferences, 'save'>;

on the DashboardApp-shaped interface. Its only real justification was the cell-detail
drawer's resize persistence: openCellDetailattachDrawerResize used to read
state.cellDrawerPx + prefs.save.

After #586 that path is gone. Cell detail from Dashboard always docks into the shell-owned
inspectorHost, and resize is owned by app-shell.ts writing the single rightInspectorPx
preference (one canonical write, src/ui/splitters.ts:140). So prefs.save is no longer
exercised through that call.

#586 updated the field's doc comment in place to say exactly this and deliberately kept the
field, so a future narrower caller gets a compile-time signal instead of a runtime crash. That
was the right call for a refactor phase whose contract said nothing about it — but the field is
now vestigial, and a comment explaining why a field is unused is a weaker guarantee than not
having the field.

Why deferred

Dropping it changes the DashboardApp structural shape and touches every construction site
plus the as ResultsApp cast next to it. That is decomposition work, not shell-primitive work.

Suggested home

Phase 5 of #593 (#589 — extract the dashboard tile gesture controller and a pure repaint
plan) already rewrites this file's seams and is the natural place to drop it. Phase 4 (#588,
composition-root decomposition) is the alternative if the field turns out to be load-bearing for
staged construction.

Not urgent, no user-visible effect, no correctness risk today.

Acceptance

  • prefs is removed from src/ui/dashboard.ts's DashboardApp interface, or a comment
    records a current reason it must stay that does not rest on the deleted
    attachDrawerResize path.
  • npm test, npm run check:types, npm run check:arch pass.
Lenguaje dominante
TypeScript
Estrellas
8
Forks
2
Merge medio
1 h 34 min
PR fusionados (30 d)
6

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Altinity/altinity-sql-browser

Todos los issues de Altinity/altinity-sql-browser

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.