Contexto
La mayoría de los propietarios nunca piensan en cómo circula la electricidad por su casa hasta que algo deja de funcionar.
Los sistemas energéticos residenciales modernos son sorprendentemente complejos. Una sola instalación puede incluir baterías, inversores solares, contadores de red, cargadores para vehículos eléctricos, pasarelas de respaldo y un panel eléctrico principal, todo ello conectado en configuraciones que varían significativamente de una casa a otra.
El reto no consistía solo en visualizar esta topología con precisión, sino en hacerla comprensible para usuarios no técnicos en tiempo real.
Fui responsable de esta función de principio a fin: desde las primeras conversaciones de diseño hasta la arquitectura, la implementación y el lanzamiento en producción. El objetivo era crear algo tan intuitivo como la pantalla de un termostato, pero que representara un sistema con docenas de estados posibles y combinaciones de hardware.
El diagrama
Simplified topology — real diagrams reflect each home's specific hardware configuration.
El diagrama se construyó con React Flow.
Cada tipo de dispositivo —batería, inversor solar, medidor de red, conector de pared, panel principal— se representa como un componente de nodo personalizado. Los bordes son más que conectores estáticos: visualizan el flujo de energía direccional en tiempo real, con una velocidad y dirección de animación que dependen directamente de la telemetría en vivo.
La topología en sí es completamente dinámica.
Algunas viviendas tienen varias unidades de batería. Otras tienen paneles solares acoplados a CA con sistemas de inversores independientes. Algunas instalaciones no tienen paneles solares. El diagrama se construye a partir de las cargas útiles de configuración devueltas por el backend, en lugar de partir de un diseño predefinido.
Esta distinción terminó dando forma a la mayor parte de la arquitectura.
Problemas complejos
Dimensionamiento dinámico de grupos
Los grupos de React Flow requieren dimensiones explícitas.
El problema es que los sistemas de energía no vienen con diseños predecibles. Un grupo de "Powerwalls" puede contener una batería o seis, dependiendo de la instalación del cliente.
Inicialmente, intenté dimensionar los grupos usando heurísticas estáticas y rápidamente me encontré con nodos superpuestos y desajustes en el diseño a medida que las configuraciones se volvían más variadas.
La solución final fue un cálculo de dimensionamiento previo al diseño que inspecciona la carga útil de la configuración antes de la renderización. Cuenta los dispositivos dentro de cada grupo y deriva las dimensiones del contenido real: alturas de los nodos, constantes de espaciado, relleno interno y reglas de diseño, no números mágicos arbitrarios.
Como el dimensionamiento se realiza antes de la renderización, los grupos se muestran correctamente en la primera impresión sin correcciones posteriores a la renderización ni cambios bruscos en el diseño.
Separación entre diseño y renderizado
Esta se convirtió en la decisión arquitectónica más importante del proyecto.
La visualización del flujo de potencia se actualiza continuamente. Los bordes se animan a una frecuencia cercana a la de los fotogramas de animación para representar el movimiento de energía en tiempo real a través del sistema.
Sin embargo, los cálculos de diseño son relativamente costosos y solo se ejecutan cuando cambia la topología del dispositivo.
Las primeras versiones del diagrama mezclaban ambas preocupaciones. Cada actualización de telemetría activaba recálculos de diseño, lo que provocaba inmediatamente caídas de fotogramas y animaciones entrecortadas una vez que comenzaba la transmisión de datos reales.
La solución fue la separación arquitectónica.
El diseño se ejecuta solo cuando cambian los datos de configuración y produce un árbol de nodos y bordes estable. La capa de animación lee de ese árbol de forma independiente sin modificar el estado del diseño.
Esta separación fue lo que permitió una renderización fluida a 60 fps incluso con actualizaciones continuas de telemetría.
Posicionamiento de los manejadores
Las aristas de React Flow se conectan mediante identificadores (handlers) asociados a los nodos.
En un diagrama de flujo estándar, los identificadores suelen estar en posiciones fijas: izquierda, derecha, arriba o abajo.
Este modelo resultó rápidamente ineficaz para los sistemas de energía residenciales.
Las líneas de conexión debían surgir dinámicamente en función de la topología circundante. Una batería situada a la izquierda del panel principal se conecta de forma diferente a una situada debajo. Los sistemas solares, los contadores y los conectores de pared introducían requisitos de enrutamiento ligeramente distintos.
Finalmente, desarrollé un sistema de configuración de identificadores que tiene en cuenta la topología, donde los nodos determinan sus puntos de conexión en relación con las posiciones de los dispositivos vecinos, en lugar de direcciones predefinidas.
Esto permitió que los diseños mantuvieran una coherencia visual incluso cuando las configuraciones de los dispositivos cambiaban drásticamente entre hogares.
Límite de la Federación de Módulos
El diagrama se encontraba dentro de una microarquitectura frontend que utilizaba la Federación de Módulos con Rspack.
React Flow es una dependencia relativamente pesada con su propio contexto de React. Cargarla ingenuamente a través de los límites de la federación introdujo instancias de dependencia duplicadas, proveedores defectuosos y un estado interno inconsistente entre las aplicaciones host y remotas.
La solución fue una externalización cuidadosa de las dependencias.
React, ReactDOM y React Flow se declararon como singletons compartidos en la configuración de la federación, con estrictas restricciones de versión para evitar incompatibilidades entre aplicaciones desplegadas de forma independiente.
Es uno de esos problemas que parecen insignificantes hasta que todo deja de renderizarse aleatoriamente.
Lo que haría diferente
El motor de diseño fue adquiriendo complejidad con el tiempo a medida que se introducían nuevos tipos de dispositivos y casos límite.
Lo que comenzó como una función de diseño sencilla evolucionó gradualmente hasta convertirse en una colección centralizada de ramas condicionales que gestionaban combinaciones específicas de dispositivos y excepciones de renderizado.
Con más tiempo disponible, refactorizaría el sistema para implementar un sistema de diseño basado en estrategias, donde cada grupo de dispositivos gestionara sus propias reglas de dimensionamiento y posicionamiento de forma independiente, en lugar de depender de una capa de orquestación compartida.
También invertiría en pruebas de regresión visual desde el principio.
El diagrama admite muchas configuraciones de hardware válidas, y validar manualmente la corrección del diseño se volvió cada vez más laborioso a medida que el sistema evolucionaba. Las pruebas visuales basadas en instantáneas, comparadas con configuraciones de topología conocidas, habrían detectado desviaciones en el diseño y regresiones de renderizado mucho antes.
Reflexiones finales
Una de las partes más interesantes del proyecto fue darnos cuenta de que el verdadero desafío no era renderizar nodos y aristas.
El desafío consistía en traducir la complejidad de la infraestructura a un lenguaje que los propietarios pudieran comprender al instante.
A la mayoría de los usuarios no les importan los árboles topológicos, las canalizaciones de telemetría ni el rendimiento de renderizado. Lo que les importa es responder preguntas como:
- ¿Se está cargando mi casa ahora mismo?
- ¿Por qué se está inyectando energía a la red?
- ¿Están mis baterías alimentando la casa?
El diagrama funciona cuando esas preguntas dejan de parecer técnicas.
Ese era el verdadero problema del producto, más allá de toda la ingeniería.