Hola a todos,
Tras la discusión sobre las tarifas de fin de semana y la respuesta de @pierre-gilles en Gladys#2999, aquí está la solicitud de funcionalidad correspondiente.
El principio, primero. Pierre-Gilles propuso mantener el núcleo genérico y permitir que las integraciones externas declaren nuevos tipos de contrato, en lugar de apilar en el núcleo casos específicos de cada país. Estoy completamente de acuerdo, y al mirar el código, encuentro que es aún más pertinente de lo que pensaba: la arquitectura ya va en esa dirección, principalmente falta abrir la puerta.
Hay que señalar que @mutmut ya ha abierto una solicitud sobre la gestión de tarifas según el día, la temporada y las vacaciones. Esta no la reemplaza: la suya describe la necesidad del usuario, esta describe el mecanismo técnico que permitiría responder a ella sin sobrecargar el núcleo. Las dos son complementarias.
Lo que ya existe y que va en la dirección correcta
server/services/energy-monitoring/contracts/contracts.calculateCost.js ya es un diccionario indexado por tipo de contrato, donde cada entrada es una función de cálculo con una firma uniforme:
(energyPricesAtConsumptionDate, consumptionDate, consumptionValue, systemTimezone, context) => cost
Es exactamente un punto de extensión. Mejor aún: el parámetro context ya se utiliza para inyectar datos externos — Tempo recibe edfTempoHistoricalMap, es decir, un calendario de colores de días recuperado en otro lugar. El precedente de un tipo de contrato que depende de una fuente de datos externa ya está establecido.
En cuanto al almacenamiento, hour_slots es una simple cadena libre y subscribed_power también. Una integración externa podría codificar en ellas lo que desee sin tocar el esquema.
Lo que bloquea
Cuatro obstáculos, del más difícil al más simple:
- El modelo SQL. En
server/models/energy_price.js, la columnacontractes unDataTypes.ENUM(...ENERGY_CONTRACT_TYPES_LIST), yday_typeunENUM(...ENERGY_PRICE_DAY_TYPES_LIST). Este es el verdadero bloqueo: añadir un tipo requiere una migración de base de datos, algo que una integración externa no puede hacer. - La lista fija
ENERGY_CONTRACT_TYPESenserver/utils/constants.js, que alimenta este ENUM y la validación del servidor. - El diccionario de cálculo no es registrable: los tres controladores están escritos en el módulo.
- El front-end, con
KNOWN_CONTRACT_TYPESenImportPrices.jsxy los rótulos encontractTypesde los archivos i18n.
Lo que propongo
a) Cambiar contract y day_type de ENUM a STRING, desplazando la validación a la capa de aplicación (contra la lista de tipos registrados, núcleo + integraciones). Una convención de nombres por integración evitaría colisiones, por ejemplo <service>:<type>. Este es el cambio estructurante: sin él, ninguna extensión externa es posible.
b) Exponer una API de registro en el servicio, en el espíritu de:
gladys.energyMonitoring.registerContractType({
id: 'edf-zen-week-end',
calculateCost: async (prices, date, value, timezone, context) => { ... },
});
La firma ya es la de los controladores existentes, por lo que los tres tipos actuales podrían migrarse a este mecanismo sin cambiar nada de su lógica — buena manera de validar la API de paso.
c) Hacer que la pantalla de importación sea controlable por los datos: la lista de tipos y el rótulo provienen de los tipos registrados, con un retroceso limpio cuando no existe ninguna traducción. El selector de intervalos horarios actual seguiría siendo el comportamiento predeterminado.
d) Opcional, para más tarde: permitir que la integración declare el tipo de editor de precios que necesita, o incluso que proporcione su propia pantalla.
Con esto, una integración « energía Francia » podría llevar Zen Week-End, Tempo, las ofertas de Engie / OHM / Enercoop y los casos estacionales de @mutmut, sin que el núcleo tenga que conocer el calendario de días festivos franceses.
Una pregunta abierta
Hoy en día, las tarifas viven en el repositorio comunitario energy-contracts, y es valioso: cuando alguien actualiza los precios de EDF, todos se benefician. Si los tipos específicos de un país se van a una integración externa, ¿adónde van los datos de precios? ¿Se quedan en energy-contracts con la integración que solo añade la lógica de cálculo, o también se mudan?
Tengo una preferencia por la primera opción — mantener un único repositorio de tarifas, compartido, y solo sacar el código de negocio — pero es realmente una pregunta, no una posición firme.
¡Gracias!
!!! No creo que tenga tiempo de probar tu imagen pronto, pero esto responde a mi problema (y a muchos otros de paso 
)
