Notas de ingeniería · Arquitectura
Tiempo de lectura · 8 min
Cómo funciona StackLiberate
Una descripción técnica de cómo StackLiberate usa identidad estable, operaciones con tipos, plantillas conscientes de capacidades, control de revisiones y exportaciones deterministas para crear un editor visual basado en la propiedad.
Un creador visual de sitios web debe sentirse sencillo.
Elige una base. Cambia el contenido. Ajusta el diseño. Publica el resultado.
El sistema detrás de esa experiencia no puede permitirse ser simplista.
Los editores visuales unen varias representaciones del mismo sitio: la página visible en el editor, el proyecto guardado en el servidor, la versión que se restaurará, la vista previa y los archivos que se publican o descargan.
Si esas representaciones evolucionan de forma independiente, terminan divergiendo.
Una edición puede verse en el lienzo y desaparecer al recargar. Una versión restaurada puede no coincidir con su vista previa original. Un sitio descargado puede comportarse distinto del aprobado en el editor. Dos guardados casi simultáneos pueden sobrescribirse silenciosamente.
StackLiberate está diseñado para prevenir esa clase de fallo.
El producto es un creador visual de sitios estáticos, pero su premisa arquitectónica es más amplia:
Un sitio debe permanecer coherente durante todo su ciclo de vida y la propiedad debe ser una característica del sistema, no solo un botón de descarga.
La propiedad empieza por los archivos entregados
Muchas plataformas describen la propiedad en términos contractuales. StackLiberate también la trata como requisito técnico.
Un proyecto completo de StackLiberate puede materializarse como sitio independiente con el HTML, CSS, JavaScript, imágenes, fuentes y demás recursos necesarios para funcionar. El resultado publicado está pensado para seguir funcionando sin el editor.
Esa distinción influye en decisiones de todo el producto.
Si el sitio exportado depende de un entorno no documentado controlado por el creador, el usuario no posee plenamente el resultado operativo. Si solo el editor original interpreta una página, la portabilidad es limitada. Si mover el sitio exige rehacerlo, la exportación existe más de nombre que en la práctica.
En StackLiberate, el sitio independiente no es una ocurrencia añadida al final. La capacidad de exportación condiciona desde el principio las funciones de edición, la gestión de recursos y la representación de cambios.
El lienzo no es la base de datos
La forma más tentadora de crear un editor visual es modificar la página directamente.
El usuario selecciona un elemento, el editor cambia su nodo DOM y la pantalla se actualiza. Sirve para una demostración, pero falla cuando el cambio debe sobrevivir a recarga, Deshacer, restauración, publicación y exportación.
Por eso el documento renderizado dentro del editor de StackLiberate no se considera el estado autoritativo del proyecto.
Es una proyección.
El lienzo muestra el aspecto actual esperado del sitio, pero el DOM visible no es el único registro fiable de cómo se llegó a ese estado. Las ediciones significativas son operaciones estructuradas sobre partes conocidas del sitio.
Conceptualmente, el flujo es:
Acción del usuario ↓ Operación de edición validada ↓ Estado local del proyecto → Lienzo y recuperación local ↓ confirmación del servidor Revisión confirmada ├── Vista previa de revisión ├── Versiones guardadas ├── Sitio publicado └── Exportación portableUn borrador local puede contener cambios más nuevos que la revisión confirmada. Restaurar valida un punto guardado y establece una revisión actual nueva; es una transición de estado, no solo otro renderizado del lienzo.
Esta separación importa porque el HTML renderizado optimiza la presentación, no la conservación de la intención de edición.
Dos páginas pueden verse idénticas y representar operaciones distintas. Un título cambiado no equivale a insertar HTML arbitrario. Reordenar una sección no es reemplazar todo el documento. Actualizar un enlace no debería marcar contenido ajeno como modificado.
Al conservar esa distinción, el sistema razona con más precisión sobre los cambios.
Identidad estable antes de modificar
Las operaciones estructuradas solo sirven si apuntan a entidades estables.
La posición no es una identidad fiable. «El tercer párrafo de la segunda sección» puede señalar otro elemento tras reordenar una sección o insertar un elemento repetible.
StackLiberate asigna identidad canónica a las superficies declaradas editables. Textos, enlaces, imágenes, secciones, páginas y elementos repetibles se pueden localizar sin depender solo de su posición temporal en el árbol renderizado.
Así una operación expresa intención:
- Cambiar esta superficie de texto declarada.
- Actualizar el destino de este enlace.
- Reemplazar esta referencia de imagen.
- Mover esta sección identificada.
- Duplicar este elemento repetible.
- Ocultar esta sección concreta.
La implementación requiere más disciplina que transmitir modificaciones arbitrarias, pero el resultado es más fácil de entender.
La identidad estable permite reproducir operaciones y validar objetivos. Hace más preciso Deshacer y más visibles los fallos: si un objetivo ya no existe o cambia su capacidad declarada, el sistema puede rechazar la operación en lugar de aplicarla en algo solo parecido.
Las plantillas declaran qué pueden preservar
Un editor puede mostrar fácilmente más controles de los que puede admitir de verdad.
Un selector de estilo puede modificar el lienzo y producir un cambio que no sobreviva a exportación. Un control estructural puede funcionar en una plantilla y dañar otra. Un inspector genérico puede asumir que dos componentes parecidos comparten contrato.
StackLiberate evita deducir la capacidad de edición solo del aspecto.
Las plantillas y recetas de sección declaran sus capacidades admitidas. El editor usa esas declaraciones para decidir qué acciones ofrecer con seguridad.
Esto crea una invariante importante:
La interfaz no debe ofrecer una edición si el sistema no sabe guardarla, reproducirla, restaurarla y exportarla.
No significa que toda parte de cada plantilla deba ser editable. Significa que la edición admitida debe ser explícita.
Una capacidad limitada pero correcta en todo el ciclo de vida aporta más valor que un control amplio que solo funciona en la sesión actual.
A eso llamamos capacidad de edición fiel.
Los cambios son operaciones, no instantáneas de accidentes
StackLiberate conserva un registro ordenado de operaciones aceptadas, ligado a un documento inicial verificado y los recursos necesarios para reconstruir los cambios.
Los cambios parciales forman parte de la proyección: una operación aceptada puede producir varias actualizaciones acotadas de un documento renderizado. Esos cambios derivados no son por sí solos el estado autoritativo. Distintas operaciones tienen datos y reglas diferentes porque cambiar texto no es mover una sección ni modificar metadatos de página.
Las operaciones tienen tipos, se validan y son reversibles donde el producto promete reversión.
Así el sistema conserva la intención sin reemplazar todo el proyecto en cada interacción. También establece límites más claros de persistencia local, confirmación del servidor, historial y validación.
El objetivo no es crear el mayor sistema de eventos posible. Es que cada cambio aceptado tenga un significado comprensible y recorra el ciclo de vida sin que cada subsistema lo interprete de otra forma.
Un estado de proyecto, varias proyecciones
Editar, reabrir trabajo guardado, previsualizar, publicar y exportar son experiencias distintas, pero no deben reinterpretar el sitio por separado.
StackLiberate usa un modelo compartido y operaciones aceptadas, distinguiendo trabajo local de revisión confirmada por el servidor. Las vistas previas del servidor, versiones y archivos finales usan estado confirmado.
No significa que toda proyección sea idéntica byte a byte. La vista del editor puede incluir controles de selección y comunicación que nunca deben aparecer en un sitio publicado. Una descarga puede organizar recursos de otra forma que la vista previa activa.
Para la misma revisión confirmada, el resultado creado debe ser consistente. Compararlo con cambios pendientes más nuevos del lienzo es comparar estados distintos.
Una sección oculta debe seguir oculta tras recargar y no reaparecer en el ZIP. Una sección movida debe conservar su posición en vista previa, restauración y exportación. Una imagen reemplazada debe apuntar al recurso previsto. Un punto restaurado debe reconstruir su estado, no aproximarlo desde el DOM actual.
Mantener alineadas esas proyecciones es una restricción continua de ingeniería, no una función de exportación que se resuelve una sola vez.
Las revisiones evitan sobrescrituras silenciosas
Guardar introduce otra clase de problemas.
Las solicitudes pueden completarse fuera de orden. Un navegador reintenta. Una respuesta lenta llega después de una operación nueva. Dos pestañas tienen visiones distintas del proyecto. Las acciones rápidas producen escrituras superpuestas.
StackLiberate usa revisiones explícitas y controles de concurrencia optimista para detectar escrituras obsoletas.
Un cambio se acepta contra una revisión esperada. Si el estado autoritativo avanzó, el sistema no finge silenciosamente que ambos escritores modificaron la misma versión.
Este patrón suele llamarse comparación e intercambio, o CAS.
Las comprobaciones de revisión complementan una única sesión activa de edición por sitio. StackLiberate admite acceso compartido, no coedición simultánea en tiempo real. Los colaboradores trabajan por turnos; el sistema no fusiona ediciones concurrentes de varias personas en un documento compartido en vivo.
La propiedad importante para el usuario es más sencilla: el trabajo nuevo no debe reemplazarse silenciosamente por una solicitud creada desde un estado antiguo.
Los puntos de control también llevan identidad y verificación para que el historial señale estados concretos. Restaurar es una transición de estado con semántica de revisión, no una copia informal.
Ningún modelo de concurrencia elimina todos los fallos. El objetivo es hacer los conflictos explícitos y recuperables, no invisibles.
El editor y el sitio están aislados
El sitio editado se ejecuta en un iframe aislado. Así las plantillas se renderizan como sitios, manteniendo la interfaz de la aplicación, autenticación y controles fuera de la página.
La comunicación cruza ese límite mediante un protocolo de puente definido.
El puente no da autoridad al iframe. Informa selecciones, solicita operaciones admitidas y recibe instrucciones para renderizar el estado actual del proyecto.
Los mensajes que cruzan el límite se consideran entrada no confiable.
El backend verifica de forma independiente las condiciones importantes antes de aceptar cambios persistentes: acceso autorizado, revisión esperada, capacidades declaradas y restricciones de seguridad del contenido. Las comprobaciones del cliente mejoran la experiencia, pero no son el límite final de autorización.
El mismo principio vale para la exportación: los mecanismos exclusivos del editor no deben filtrarse al sitio autónomo.
El aislamiento solo sirve si el límite sigue claro.
La exportación es un proceso de materialización
Exportar un sitio no equivale a guardar el contenido actual del iframe.
El editor contiene estado temporal y comportamientos que nunca deben formar parte del sitio del usuario. El DOM actual también puede reflejar estados transitorios, cargas o instrumentación de edición.
StackLiberate materializa el proyecto desde su estado creado confirmado.
Durante ese proceso aplica operaciones aceptadas, resuelve recursos, conserva interacciones admitidas, elimina comportamientos exclusivos del editor y produce los archivos del sitio independiente.
La exportación está diseñada para ser determinista: con el mismo documento inicial retenido, cambios aceptados, recursos verificados y configuración pertinente, debe reproducir el mismo resultado. No reconstruye un sitio antiguo sustituyendo silenciosamente la plantilla por la más reciente del catálogo.
El determinismo permite reproducir fallos y probar paridad. También da más sentido a la propiedad porque el proyecto exportado deriva de un estado explícito, no de capturar un momento opaco del navegador.
La independencia del editor no elimina dependencias externas. Un mapa, destino de formulario u otra integración admitida puede seguir necesitando su proveedor.
El fallo forma parte del diseño
Los usuarios no interactúan con el software en secuencias perfectamente espaciadas.
Hacen doble clic. Cambian rápido de página. Recargan al guardar. Vuelven atrás. Las redes se interrumpen y regresan. Las pestañas quedan abiertas. Las solicitudes llegan tarde. Los navegadores se cierran.
Un sistema que solo funciona si cada acción termina en el orden ideal no es fiable.
Por eso StackLiberate trata las interacciones rápidas y los fallos parciales como condiciones normales. Según la operación, usa comprobaciones de revisión, transacciones, idempotencia, transiciones protegidas, reproducción determinista o bloqueo cuando no puede demostrar que el cambio sea seguro.
Bloquear ante incertidumbre no significa mostrar un error por cada condición inusual. Significa negarse a inventar éxito.
Si una operación no puede aplicarse al objetivo previsto, su revisión es obsoleta o una capacidad no está declarada, conservar el estado conocido es más seguro que producir silenciosamente uno desconocido.
Restricciones deliberadas
StackLiberate no está diseñado para ser cualquier tipo de plataforma web.
Se centra en sitios estáticos profesionales que se benefician de edición visual, buenas bases, publicación sencilla y la posibilidad de salir de la plataforma con un resultado útil.
Ese enfoque permite garantías más sólidas.
Un sistema con aplicaciones de servidor arbitrarias, código externo sin restricciones, coedición simultánea, comercio electrónico y todos los modelos de contenido requeriría otra arquitectura y otro perfil de riesgo.
StackLiberate elige plantillas controladas, capacidades declaradas, operaciones acotadas y archivos portables.
Las restricciones no son límites accidentales alrededor del producto. Ayudan a definirlo.
Las concesiones que aceptamos
La edición fiel tiene límites deliberados
StackLiberate no es un lienzo libre para arrastrar objetos a cualquier coordenada o transformarlos sin límites. Es un creador basado en plantillas.
Los usuarios tienen amplio control sobre contenido declarado, estilos, imágenes, secciones, páginas, navegación y estructuras repetibles, pero solo donde plantilla y editor preserven los cambios de forma fiable.
Es una restricción real. Un lienzo sin límites ofrece más libertad creativa inmediata, pero complica mucho garantizar adaptación a pantallas, accesibilidad, coherencia, restauración y exportación portable.
StackLiberate elige flexibilidad acotada frente a controles que solo funcionan en condiciones ideales. Ampliamos esos límites con más plantillas, variantes de sección, estilos y operaciones explícitas, no presentando modificaciones arbitrarias como edición fiable.
No buscamos impedir la personalización, sino que siga siendo válida tras recargar, en distintos tamaños de pantalla, a través del historial y fuera de StackLiberate.
Paridad no significa identidad byte a byte
No se espera que la vista del editor y el sitio exportado sean idénticos byte a byte.
El iframe contiene instrumentación del editor: selección, comunicación, estado temporal y otros mecanismos que no deben aparecer en el sitio independiente. Las rutas de recursos y archivos generados también pueden diferir entre entornos.
El contrato de paridad se aplica al resultado creado:
- contenido;
- estructura;
- orden y visibilidad de secciones;
- estilos;
- recursos;
- navegación;
- y comportamiento interactivo admitido.
Al comparar la misma revisión confirmada, esas propiedades deben ser consistentes en vista previa, reapertura, publicación y exportación, aunque difieran el entorno y los bytes generados. Restaurar un punto establece la revisión actual que usarán las salidas posteriores.
Mantener el contrato requiere trabajo continuo. Las nuevas capacidades deben admitir persistencia, reproducción, restauración y exportación, no solo verse en el lienzo. StackLiberate usa operaciones compartidas, materialización determinista, comprobaciones de capacidades y pruebas de paridad para reducir divergencias.
No hace imposibles las regresiones. Hace de la paridad una invariante explícita y comprobable en lugar de una suposición.
Sencillo por fuera, disciplinado por dentro
La mayoría de usuarios no deberían pensar en identidad estable, reproducción de operaciones, concurrencia, materialización ni aislamiento de iframes.
Deberían elegir un sitio, editarlo, publicarlo y ser dueños del resultado.
La ingeniería existe para hacer real esa experiencia sencilla.
Cuando StackLiberate dice que un sitio es portable, la exportación debe respaldarlo. Si ofrece una acción, el modelo de estado debe preservarla. Si restaura una versión, el resultado debe corresponder a un punto conocido. Si chocan dos escrituras, no debe descartar una en silencio.
Un creador visual es, en definitiva, un sistema de gestión de estado con una interfaz de diseño.
Construimos StackLiberate para que la interfaz sea accesible y el estado subyacente siga siendo explícito, verificable y portable.
Así pueden coexistir la edición visual y la propiedad real.