/resumen/movimientoscategoría · ingresos vs salidas · forecast
montan al llegar al viewport
Consolidar dos vistas que ya comparten datos y competencia, sin perder la regla core (comprar ≠ pagar).
Ambas viven del mismo hook useFinance().cashflow(y, m0) y muestran lo que sale del bolsillo este mes (§6). El overlap es real, no cosmético.
/ — KPI hero, lista por monto, charts en columna derecha (desktop)<RecurringIncomeMonth /> — sueldos recurrentes, monto editable inline.PieByCategory + IncomeVsOutflow.useFinance(), useExpenses(), useCategories(), useMonth().AppShell)./gastos — toggle pago/compra, lista por día, edición inlineuseCards(), useCardPeriods().QuickAddSheet con el expense./forecast): meses hacia adelante, agrupado por tipo (compras / cuotas / fijos / cash). Regla §7 — no se toca./graficas): duplica los charts del Resumen + el ForecastBars. candidato a absorber/ingresos): ingresos sueltos + plantillas recurrentes. No aparece en el nav (se accede desde el hero recurrente).Nav actual (mobile bottom + desktop side): NAV_ITEMS tiene 6 items — Resumen, Gastos, Forecast, Gráficas, Tarjetas, Categorías. Unificar libera un slot.
| Feature | Resumen | Gastos (Por pago) |
|---|---|---|
| Fuente de datos | cashflow(y, m0).items |
cashflow(y, m0).items idéntico |
| Orden | por monto desc | por día de pago asc |
| Editable | no | sí |
| KPI del mes | sí (hero) | no |
| Charts | sí (desktop) | no |
Conclusión: dos vistas del mismo mes con features complementarias. El costo de saltar entre ellas para "ver cuánto queda y editar un gasto" no se justifica.
Tres shapes candidatos. Wireframes lado a lado, mobile y desktop.
Hero KPIs → últimos 10 movimientos (gastos, ingresos y pagos de tarjeta, cada uno con tag chico) → botón "Ver más movimientos →" → charts lazy (mount al viewport). La lista completa con filtros vive en la subruta /resumen/movimientos, que reusa Gastos.tsx tal cual está — cero refactor de componentes.
/resumen/movimientosByPayment dentro de Resumen + edit handler.Una sola ruta con tabs adentro. El header con selector de mes + KPI hero es siempre visible; solo cambia el bloque de abajo. Preserva la separación conceptual sin gastar espacio en el nav global.
?tab=movimientos? Deep-link o no.En desktop, layout de dos columnas: lista de movimientos a la izquierda, panel de detalle/edición + charts a la derecha. En mobile cae a la Variante A. Pensada para uso ancho, tipo dashboard financiero.
QuickAddSheet).QuickAddSheet con un panel inline.| Criterio | A · Scroll largo | B · Tabs internas | C · Master-detail |
|---|---|---|---|
| Densidad mobile | alta | media | alta |
| Densidad desktop | media | media | muy alta |
| Discoverability charts | alta | alta | solo desktop |
| Foco "cuánto queda" | hero arriba | hero fijo | hero arriba |
| Complejidad refactor | baja | media | alta |
| Reduce nav a 5 | sí | sí | sí |
| Vista "Por compra" | toggle o se elimina | tab extra | no encaja |
| Reusa código existente | ~90% | ~80% | ~50% |
Refinada con lista corta (últimos 10) + subruta /resumen/movimientos para la historia completa + charts lazy.
Es lo que menos discute con lo que ya funciona. El Resumen es de hecho la home; los usuarios ya llegan ahí a mirar "cuánto queda". Sumarle un vistazo rápido de los últimos movimientos con la capacidad de editar cierra el circuito, sin sepultar el hero bajo una lista larga.
/resumen/movimientos: lista completa con filtros (mes, categoría, medio, búsqueda). Es el Gastos.tsx actual reusado como está — cero refactor de componentes, solo cambio de ruta./gastos redirige a /resumen/movimientos. /graficas se retira.Interactivo: marca lo que ya está hecho. Sin persistencia — es solo para trackear en la sesión.
Si la lista editable domina la pantalla, el KPI hero deja de ser lo primero que se lee.
Resuelto por el refinamiento: lista corta a 10 items + "Ver más" que empuja a subruta. El hero + últimos movimientos entran en un viewport de mobile sin scroll excesivo. La historia completa vive en /resumen/movimientos.
El core §4 es que una compra con tarjeta no descuenta este mes. Al agregar filtros y edición, hay riesgo de que el user filtre "solo crédito" y vea nada, o edite una compra pensando que está viendo su día. Mitigar: mantener los tags "sale ahora" / "se paga en X"; al editar, mostrar la fecha de pago en el sheet.
PieByCategory + IncomeVsOutflow renderizan con datos completos del mes.
Resuelto por lazy render: los charts se montan con IntersectionObserver al llegar al viewport. En mobile, si el user no baja, no se ejecutan. Memoizar los cálculos del useFinance() derivados sigue siendo buena idea.
Si algún user usa la vista por fecha de compra activamente, desaparecerla molesta. Mitigar: no borrar todavía; mantener como toggle secundario adentro del bloque de lista o como deep-link.
Filtros arriba de la lista compiten con el hero por atención. Mitigar: chips discretos, ancho reducido, entre hero y lista. No mezclar con la selección de mes (que ya está en el AppShell).
/gastosUsers con la app instalada como PWA pueden tener shortcuts. Mitigar: redirect por 1 release antes de borrar.