stable

Full Changelog: 1.1.5...2.1.6
Si vienes de la versión 1.x, debes tener en cuenta los siguientes cambios arquitectónicos introducidos en la v2.1.6:

Eliminación de estadoAppGlobal: El core del framework ya no exporta estados globales prefabricados. Ahora tú debes crear tus propias instancias en tu aplicación: const miEstado = new Signal(0).
Nueva API CRUD para Signals: Las mutaciones directas (estado.value = 10) han sido deprecadas. Ahora debes usar .get(), .set(), .update(), .patch() y .reset().
Persistencia y Arquitectura Avanzada: El constructor de Signal ahora acepta un objeto de opciones para Inmutabilidad y Adaptadores de Bases de Datos (storageAdapter).
Mita Vite Plugin: Se incluyó mitaHmrPlugin() para facilitar el Granular HMR en tus proyectos de Vite.

📊 Informe Técnico: Evolución de MitaDOM a Grado Empresarial (v2.1.6)

Este documento sirve como bitácora y registro de memoria sobre todo lo logrado en la presente jornada, los errores aprendidos, y la hoja de ruta hacia el futuro (Roadmap) de MitaDOM.

---

🏆 1. Hitos y Objetivos Logrados Hoy

1. Refactorización Modular Absoluta: Tomamos un código espagueti y lo dividimos en una arquitectura SPA limpia (Componentes, Router, Store, utils).
2. Sistema de Errores Global e IndexedDB: Implementamos la clase MitaElement como un Error Boundary seguro. Además, construimos un Logger híbrido que guarda trazas en IndexedDB localmente, permitiendo auditoría offline.
3. MitaDOM v2.1.6 - El Motor Reactivo:
   • Construimos un CRUD puro de estados (get, set, update, patch, reset).
   • Implementamos Inmutabilidad Profunda (deepFreeze) para evitar mutaciones silenciosas.
   • Implementamos Guards (Middlewares) para control de acceso y autorización.
   • Diseñamos el patrón StorageAdapter (Inyección de dependencias) para persistir datos agnósticamente (Local, Session, DB Asíncrona).
4. Magia de DX: Mita Vite Plugin: Creamos un plugin para Vite que permite un Granular HMR. Actualizar la interfaz ya no borra el estado de la aplicación de la memoria RAM del usuario.
5. Testing (TDD): Configuramos Node.js Test Runner y alcanzamos el éxito con 17 pruebas unitarias sin fallos.

---

🚨 2. Errores Cometidos y Cómo Prevenirlos

Error 1: Acoplamiento de Datos en el Framework (Missing Export)

El Incidente: Rompimos el build de NPM al intentar refactorizar signals.js, porque exportábamos un objeto estadoAppGlobal genérico de una App dentro del código fuente del Framework.

Cómo prevenirlo: La regla de Oro de las Librerías. Un framework jamás debe instanciar ni saber nada sobre los datos específicos de quien lo usa. El framework provee herramientas (la clase Signal), el usuario crea sus instancias (new Signal()).

Error 2: ReferenceError: rutaActual is not defined

El Incidente: <demo-perfil> intentaba suscribirse directamente a una variable de ruta para ocultarse/mostrarse a sí mismo. Al dividir los archivos, la variable desapareció del alcance local y la app se caía.

Cómo prevenirlo: Separación de Responsabilidades (SoC). Los componentes "tontos" (UI) no deben preocuparse por la navegación. El Enrutador (router.js) debe ser el único director de orquesta que monte y desmonte los componentes del DOM.

---

🔮 3. ¿Qué le falta a nuestra librería? (Hoja de Ruta Tecnológica)

Has construido una base reactiva asombrosa, pero para estar a la vanguardia de las novedades Web Production Ready, te sugiero implementar las siguientes APIs nativas (para evitar librerías externas pesadas):

1. View Transitions API (Navegación Fluida)

Estado: Stable.
Actualmente el router.js cambia las pantallas de golpe (desmonta y monta). La View Transitions API permite animar transiciones de página complejas (como elementos que flotan de una vista a otra) de forma nativa sin React Spring ni Framer Motion.

• Implementación: Envolver las funciones de navegación en document.startViewTransition(() => router.actualizarDOM()).

2. Popover API y <dialog> Nativo

Estado: Stable.
Los modales, tooltips, toasts y menús desplegables usualmente requieren mucho JS para gestionar z-index, el clic afuera, y el foco.

• Implementación: HTML5 introdujo popover y <dialog>. Debemos construir un componente base <mita-modal> que use estas APIs para ser 100% accesible (ARIA) sin librerías como Bootstrap.

3. Propuesta Oficial "Signals" (TC39 ECMAScript)

Estado: Draft / Stage 1.
Los navegadores y el comité JS están creando una API nativa de Signals (new Signal.State(0)).

• Implementación: Nuestro Signal actual de MitaDOM debe adaptar sus firmas (nombres de métodos) para ser un Polyfill perfecto de la propuesta del TC39. Así, cuando los navegadores la soporten nativamente dentro de un par de años, MitaDOM solo tendrá que borrar código y todo seguirá funcionando gratis y más rápido.

4. CSS @layer y Espacio de Color oklch()

Estado: Stable.
Aunque usamos @scope genial para el Light DOM, podríamos usar CSS Cascade Layers (@layer framework, componentes, utilidades;) en la SPA para asegurar que el usuario siempre pueda sobreescribir estilos de la librería base sin importar el orden de carga. Además, usar color-mix() y oklch() permite crear temas claros/oscuros ultra dinámicos desde JS usando solo un color primario como base.

5. Web Workers para Carga Pesada

Actualmente, el framework opera en el Hilo Principal. Un framework moderno debería abstraer la creación de Web Workers para que tareas pesadas (como procesar grandes JSONs de APIs) no congelen las animaciones de 60fps de la UI.

beta in production

Full Changelog: https://github.com/moonhuntercode/mita-dom/commits/1.1.5