Version: 1.0.0
Fecha: 26 de Junio, 2026
Arquitecto: Carlos Alberto Torres Camargo
Inventario vivo de utilidades, componentes, patrones y configuraciones reutilizables
aportados al frontend de Nebula ERP. El objetivo es que el equipo descubra lo que ya
existe y lo reutilice en lugar de reimplementarlo. Cada entrada indica qué es,
dónde está, cómo se usa y cuándo aplicarla.
Este catalogo se amplia con cada mejora reutilizable. Mantener una sola entrada por pieza.
buildSearchByTerm — busqueda libre por cualquier columnasearchsBy para los listados, evaluando el tipo deMATCH, número → EQUAL (solo si el término es numérico),EQUAL ("true"/"false").@nebula-shared/data-access (crud/search-by-term.util.ts).import { buildSearchByTerm } from '@nebula-shared/data-access';
const searchsBy = buildSearchByTerm(searchTerm, [
{ key: 'codigo', type: 'number' },
{ key: 'nombre', type: 'text' },
{ key: 'estadoTipoPlan', type: 'enum' },
{ key: 'tieneCuentasActivas', type: 'boolean' },
]);
AND + MATCH sobre columnasPlanVigenciaSelectorComponent — selector de plan contable vigente@nebula/accounting (shared contable). ConsumeGET /tipo-plan-vigencia/seleccion.[vigencia] (number, opcional) — sin valor usa la vigencia actual del backend.[autoSeleccionarPrincipal] (boolean, por defecto true).[(seleccion)] (two-way) — el plan seleccionado.(planSeleccionado) — evento al cambiar la selección.getSeleccionado() — método que devuelve el plan actual.import { PlanVigenciaSelectorComponent } from '@nebula/accounting';
<app-plan-vigencia-selector
[vigencia]="2026"
[(seleccion)]="planActual"
(planSeleccionado)="onPlan($event)" />
El backend siempre responde con la estructura estandar
{ response: { content, metadata } }. En el front, descomponer siempre con
HttpService.getContent<T>() (desenvuelve response.content). No implementar
fallbacks tipo "envelope o array".
this.http.getContent<TipoPlanVigente[]>(`${base}/seleccion`, params);
disabledform.value excluye los controles deshabilitados. Al actualizar, completar el
payload desde el item seleccionado para no enviar campos en null (causa 400).
onBeforeUpdate(payload) {
return { ...payload, codigo: this.selectedItem.codigo /* , ...campos fijos */ };
}
AuthServiceTras login o seleccion de compañía, persistir el token con el servicio
(handleSuccessfulAuth / updateTokensAfterCompanySelection), que ademas
programa el refresh proactivo. Nunca guardar el token con localStorage.setItem
manual: omite el scheduleTokenRefresh y la sesion expira sin renovarse.
this.authService.updateTokensAfterCompanySelection(token, refreshToken, expiresIn);
buildSearchByTermVer 1.1. No unir varias columnas con AND ni aplicar MATCH sobre columnas
numericas.
outputHashing en build developmentEl front de dev sirve los bundles tras un nginx con cache immutable de 1 año. Si los
bundles no llevan hash, tras cada despliegue quedan stale (parece que "no se
desplego"). Solucion: hash de bundles tambien en desarrollo.
// apps/nebula-shell/project.json -> targets.build.configurations.development
"outputHashing": "all"
| Version | Fecha | Autor | Descripcion |
|---|---|---|---|
| 1.0.0 | 2026-06-26 | Carlos Torres | Creacion del catalogo: buildSearchByTerm, PlanVigenciaSelectorComponent, patrones de respuesta/update/sesion/busqueda y gotcha de outputHashing |
Autor: Carlos Torres — arquitecto.centrica@centricasoluciones.com
Proyecto: Nebula ERP — Centrica Soluciones