That Open Components: piezas abiertas para construir tu visor BIM
El prototipo abría un IFC, permitía orbitar y cambiaba el color de los muros. En la demo parecía un visor terminado. Al preparar el piloto, aparecieron preguntas sobre modelos grandes, propiedades, versiones, interfaz, permisos y errores. El equipo había construido la escena 3D; la aplicación todavía estaba por llegar.
That Open Components ofrece piezas reutilizables para desarrollar experiencias BIM en web, dentro de un ecosistema que puede incluir componentes de núcleo, geometría fragmentada, lectura IFC e interfaz. No es una plataforma monolítica que resuelva usuarios, proyectos y colaboración al instalar un paquete. Su valor está en componer capacidades con control; su coste está en asumir arquitectura, integración y mantenimiento.
Tabla de contenidos
El equipo dibujó responsabilidades antes de instalar más paquetes
La primera fase necesitaba cargar IFC, navegar, consultar propiedades y aislar elementos. La siguiente incorporaría versiones e incidencias. El backend gestionaría proyectos, permisos y procesamiento.
El mapa separó motor BIM, representación gráfica, componentes UI y aplicación. También indicó dónde vivían archivos, jobs y estado. Esta frontera impedía guardar toda la lógica en eventos del visor.
La librería resolvería piezas técnicas. El equipo seguía respondiendo por seguridad, experiencia, datos y operación. Saberlo pronto evitó pedir al componente una función que pertenecía al producto.
El núcleo coordinó componentes, no el negocio
Los componentes compartían contexto y ciclos de vida. El equipo inicializaba mundo, escena, cámara y renderizador según las APIs vigentes. Después añadía capacidades concretas.
La configuración se concentró en un módulo de infraestructura. Las pantallas no creaban instancias paralelas ni listeners huérfanos. Al desmontar una vista, se liberaban recursos.
El dominio recibía eventos traducidos: elemento seleccionado, modelo cargado o error. No dependía de cada nombre interno. Esta capa permitía probar negocio sin WebGL y actualizar componentes con menos daños colaterales.
IFC y fragments ocuparon momentos distintos
El IFC era el intercambio de origen. Leerlo en navegador podía servir para archivos y flujos compatibles. Para rendimiento y distribución, una representación fragmentada o procesada podía encajar mejor, según el ecosistema y versión.
El equipo decidió si convertir en cliente o backend. El navegador simplificaba infraestructura y trasladaba CPU, memoria y archivo al dispositivo. El servidor permitía procesar una vez, controlar versiones y entregar artefactos optimizados.
Los fragments no sustituían el IFC como evidencia original. Se vinculaban con modelo, versión y configuración. Si cambiaba el procesamiento, podían regenerarse.
web-ifc se trató como parser, no como validador total
La lectura permitía acceder a entidades, propiedades y geometría. El equipo controlaba carga, progreso y errores. Los modelos de prueba incluían esquemas y entidades relevantes.
Abrir el archivo no demostraba cumplimiento de requisitos. Las validaciones de esquema, información y uso seguían su flujo. El visor mostraba resultados, pero no adquiría autoridad por conocer IfcWall.
Las versiones y compatibilidad se fijaban. Actualizar el parser activaba pruebas sobre modelos conocidos. El comportamiento se verificaba en documentación actual, no en un ejemplo antiguo.
La interfaz se diseñó alrededor de tareas
Los componentes UI podían acelerar paneles, botones y relaciones con el visor. El equipo los evaluó por accesibilidad, personalización y compatibilidad con su framework.
La aplicación necesitaba árbol, propiedades, búsqueda y estados. No mostraba cada herramienta disponible. Un coordinador debía completar una revisión sin aprender la arquitectura interna.
Las acciones podían ejecutarse por teclado y existían rutas tabulares. El 3D aportaba contexto; la interfaz no podía depender únicamente de hacer clic sobre geometría pequeña.
El framework de frontend siguió siendo una decisión propia
El ecosistema podía integrarse con JavaScript o TypeScript y distintas arquitecturas. El equipo aisló componentes web o adaptadores para utilizarlos desde su framework.
Los micro frontends no se adoptaron solo porque existiesen piezas desacopladas. Se justificaban si equipos, despliegues y fronteras lo requerían. Para una aplicación pequeña, habrían añadido coordinación.
El estado del visor se mantuvo separado del estado remoto. Seleccionar un objeto era local; cerrar una incidencia necesitaba API, permisos y confirmación. Mezclarlos habría producido una interfaz optimista con memoria selectiva.
Los modelos grandes obligaron a medir
Se probaron un IFC pequeño, uno federado y otro con geometría compleja. El equipo midió procesamiento, memoria, primera vista útil y respuesta de selección.
Los resultados guiaron estrategias: conversión previa, carga por modelos, índices de propiedades y liberación de recursos. No se prometió un tamaño máximo universal.
Los dispositivos modestos formaron parte. Una librería eficiente no elimina límites del navegador. Cuando un modelo excedía capacidad, la aplicación explicaba y ofrecía alternativas.
Las propiedades necesitaron un índice y un vocabulario
Consultar una selección era distinto de filtrar todo el edificio. Para búsquedas y análisis se preparaban estructuras adecuadas. Las propiedades visibles se mapeaban a un esquema interno.
El equipo distinguía tipo e instancia, unidades y valores ausentes. Los nombres del IFC no se convertían directamente en etiquetas de negocio sin revisar.
Los datos derivados podían vivir en backend. El componente de visor no se utilizaba como base analítica. Dibujar y consultar una propiedad no implica resolver informes masivos.
La selección se tradujo antes de salir del visor
Los IDs gráficos o internos podían depender del artefacto. La aplicación relacionaba selección con modelo y versión. Para trazabilidad entre versiones utilizaba claves estables cuando existían.
Una incidencia guardaba cámara, referencias y contexto. Si un elemento desaparecía, se marcaba. No se reasignaba por proximidad sin revisión.
Esta traducción permitió cambiar representación sin romper el dominio. El componente sabía qué se había pulsado; la aplicación sabía qué significaba.
El backend apareció antes de la colaboración
Usuarios, proyectos, membresías, archivos y versiones vivían en una API. Los modelos se subían con permisos y se procesaban mediante jobs. El frontend recibía estados.
Las incidencias se guardaban en servidor, con historia y responsable. El visor mostraba marcadores derivados. Recargar no borraba el trabajo.
Los secretos y integraciones permanecían fuera del navegador. That Open Components ayudaba en la experiencia BIM; no sustituía la seguridad del producto.
Los workers evitaron congelar peticiones
Convertir IFC, generar índices o validar podía tardar. La API encolaba operaciones idempotentes. Los workers limitaban concurrencia y registraban progreso.
Un fallo conservaba causa y reintento. El usuario no necesitaba mantener la pestaña abierta. La misma versión y configuración no creaban procesamientos duplicados.
El artefacto generado llevaba versión del conversor. Al actualizar dependencias, podía regenerarse de forma controlada.
Las dependencias peer dejaron de ser un detalle
El equipo fijó versiones compatibles de librerías, motor gráfico, TypeScript y framework. Revisó peer dependencies y tamaño del bundle.
Las actualizaciones se agrupaban y probaban. No se utilizaban rangos amplios en producción sin control. Un cambio menor puede alterar tipos o renderizado.
El lockfile y el inventario de licencias formaban parte. Open source no significa sin obligaciones ni sin mantenimiento; significa que puedes leer con detalle el motivo de tu siguiente actualización.
La licencia se revisó por paquete y uso
El equipo comprobó licencias vigentes del núcleo, dependencias y ejemplos. También atribución, redistribución y compatibilidad con su producto.
No asumió que todo el ecosistema compartiese condiciones idénticas. Los servicios, componentes y contenido podían diferir. La revisión jurídica utilizaba fuentes actuales.
El coste de adopción incluía desarrollo, infraestructura, QA y soporte. No pagar una licencia de plataforma no elimina esos conceptos; los vuelve tuyos.
Las pruebas separaron motor, integración y producto
Las unidades validaban mappings y estado. Las pruebas de visor cargaban modelos conocidos y comprobaban selección, propiedades y liberación. Las visuales detectaban regresiones.
La integración atravesaba carga, job, artefacto y frontend. Los permisos se probaban con usuarios reales. Los modelos adversos incluían geometría y propiedades problemáticas.
La actualización del ecosistema ejecutaba el conjunto. Una demo manual no era el gate. El renderizado tiene una habilidad especial para fallar en la tarjeta gráfica que nadie usó durante desarrollo.
La observabilidad llegó al navegador
La aplicación medía tiempos y errores sin enviar datos sensibles. Los reportes incluían versión del artefacto, navegador y componente.
El backend correlacionaba procesamiento y carga. Si un modelo no abría, soporte podía distinguir conversión, red, memoria o permisos.
Las métricas guiaban mejoras. No se recogían solo para fabricar un dashboard sobre el dashboard.
Cuándo usar una plataforma terminada
Si la necesidad era visualizar y colaborar con funciones estándar, una plataforma existente podía reducir meses de desarrollo. Construir tenía sentido cuando la experiencia, integración o control eran diferenciadores.
Un equipo sin capacidad de frontend 3D y operación debía valorar soporte. Los componentes reducen trabajo, no lo hacen desaparecer.
Para un visor puntual, un ejemplo adaptado podía bastar. Para un producto multiusuario, necesitabas arquitectura, seguridad y ciclo de vida.
Las piezas abiertas terminaron formando una aplicación propia
El piloto cargó modelos procesados, consultó propiedades y abrió incidencias a través de una API. Los componentes BIM quedaron aislados detrás de contratos. El equipo podía actualizar y medir.
That Open Components ofrece una base flexible para construir, especialmente cuando quieres controlar experiencia y datos. Para adoptarlo, separa núcleo, IFC/fragments, UI y backend; prueba modelos reales; fija dependencias y asume operación.
Si el IFC gira y los muros cambian de color, celebra el prototipo. Luego abre la lista de permisos, versiones y errores. Ahí empieza la aplicación, que suele tener menos brillo y bastante más trabajo.
Respuestas