Notas de ingeniería · Arquitectura
Tiempo de lectura · 10 min
Un sitio entre edición, versiones y exportación
Cómo estado validado, cambios ordenados y recursos verificados conectan edición, restauración, vista previa y exportación mediante materialización compartida y comprobaciones de consistencia.
Un sitio creado en un editor visual existe en más contextos de los que imagina la mayoría.
Se ve en el lienzo mientras se edita, en otro entorno para revisión, se guarda como versión restaurable, se exporta como archivo descargable y puede publicarse en alojamiento de producción.
Cada contexto tiene diferentes restricciones de ejecución, recursos disponibles y expectativas sobre scripts presentes y URLs válidas.
Si se tratan como problemas de renderizado independientes, divergen. Una sección oculta reaparece al exportar. Una imagen de la vista previa tiene una URL rota en la descarga. Una restauración no coincide con lo que se recuerda haber guardado.
StackLiberate se diseña alrededor de una representación autoritativa del sitio. Los contextos materializan ese estado para distintos fines, sin mantener copias editables independientes. Lo relevante es comparar salidas de la misma revisión confirmada.
Un sitio. Varias salidas. Un estado autoritativo.
La fuente de verdad no es una página renderizada
El estado creado de un sitio de StackLiberate combina tres elementos:
- Un documento inicial validado derivado de la plantilla elegida.
- Un registro ordenado de operaciones de edición aceptadas.
- Los recursos y definiciones para reconstruir esos cambios.
Ni el lienzo, ni un iframe de vista previa, ni un ZIP anterior son la fuente de verdad. Son proyecciones del estado subyacente.
El orden importa. Editar una tarjeta después de duplicarla no equivale a editar el original y después duplicarlo. La reconstrucción evalúa cada operación contra el estado producido por las anteriores, preservando la cronología de contenido, estructura y diseño.
La representación autoritativa no es un árbol DOM en un navegador activo. Una página renderizada es una salida, no sustituye los datos y recursos para reconstruirla.
La edición actúa sobre la representación, no la vista
Al cambiar un título, el editor envía un cambio estructurado a un objetivo lógico. Puede incluir contenido y formato admitido; no es un reemplazo arbitrario del DOM de la página.
Antes de aceptarlo, el sistema comprueba objetivo, capacidades, estado previo esperado y candidato resultante. Un cambio basado en estado obsoleto o incompatible no debe sobrescribir silenciosamente trabajo nuevo.
El estado aceptado se proyecta en el lienzo para respuesta inmediata. El renderizado es transitorio; un borrador local duradero y una revisión confirmada por servidor son estados de persistencia distintos, no nombres intercambiables del mismo guardado.
La distinción es esencial para la consistencia entre contextos:
- Un borrador local puede sobrevivir a una recarga sin confirmarse en el servidor. Su recuperación depende del almacenamiento conservado por ese navegador.
- Reabrir reconstruye el estado creado desde datos retenidos, sin confiar en una página renderizada anteriormente.
- Restaurar una versión valida su estado guardado y establece una revisión actual nueva.
- Exportar materializa estado confirmado en el servidor sin leer el lienzo activo.
Así renderizado, recuperación local y persistencia del servidor se vinculan a un estado explícito, sin que cada vista sea un escritor independiente.
Las versiones capturan el estado creado
Una versión captura estado creado confirmado: cambios aceptados y referencias de origen y recursos para reproducirlos. No es solo una captura de pantalla ni una copia del HTML actual del navegador.
Guardar una versión registra un punto concreto. Restaurarla comprueba ese punto y sus recursos antes de establecer una revisión actual nueva. Es una transición controlada, no el reemplazo sin comprobación del documento abierto.
Esto tiene propiedades importantes:
Las versiones permanecen ligadas a su origen. Un punto guardado identifica su estado inicial y definiciones retenidas. No se sustituye silenciosamente por una entrada nueva del catálogo al reconstruir trabajo antiguo.
La reconstrucción se comprueba. Los cambios aceptados deben reconstruir el estado esperado. Si falta material necesario o es incoherente, se rechaza en lugar de adivinar un reemplazo.
El estado restaurado usa la ruta de salida habitual. Tras completarse Restaurar, vista previa y exportación consumen la revisión actual restaurada mediante la misma materialización de otras revisiones confirmadas.
Preservar el estado creado no congela servicios de terceros ni el comportamiento del navegador. Conserva contenido, estructura, diseño y recursos retenidos aceptados del sitio.
Vista previa y exportación comparten contrato de renderizado
Ambas deben responder la misma pregunta: «¿Qué sitio describe esta revisión confirmada?»
Comparten la proyección y materialización del servidor para ese estado. El lienzo tiene otra responsabilidad: mostrar cambios locales y controles mientras el usuario trabaja.
El contrato de renderizado es:
- Identificar y validar la revisión que se materializa.
- Reconstruir los cambios aceptados en su orden original.
- Resolver los recursos necesarios para el contexto de destino.
- Aplicar las comprobaciones y transformaciones de entrega adecuadas a esa salida.
La vista previa presenta el resultado para revisar; no es otra copia editable. La exportación empaqueta archivos estáticos y recursos, reescribe referencias portables y elimina instrumentación del editor. Los scripts públicos de navegación e interacciones admitidas siguen siendo parte del sitio.
La consistencia no exige idéntica presentación en ejecución. Los controles de selección no pertenecen a la descarga. Un acordeón abierto al editar puede empezar cerrado para visitantes. Esas diferencias no deberían cambiar el contenido creado subyacente.
El estado y la materialización compartidos reducen oportunidades de divergencia. Las pruebas aún deben verificar que presentación en navegador y archivos estáticos preserven el resultado previsto.
La identidad de un recurso es distinta de su URL
La gestión de recursos es una fuente habitual de incoherencia. Una imagen se ve bien en el editor porque usa una CDN, falla en vista previa local por una URL absoluta y un servidor distinto, y se rompe en la exportación porque nunca se descargó.
StackLiberate separa identidad de recurso y dirección de entrega. Los recursos retenidos de la plantilla y las cargas admitidas llevan información para comprobar que los bytes usados son los esperados. Una URL temporal de visualización no tiene autoridad sobre el recurso.
Cada contexto entrega esos recursos de forma distinta:
- Edición y vista previa: usan referencias de entrega apropiadas para la sesión y el contexto.
- Exportación: incluye los recursos empaquetados necesarios y reescribe sus referencias como rutas portables.
- Publicación: usa el materializador estático compartido para preparar archivos para el despliegue.
El proceso comprueba los recursos empaquetados requeridos en lugar de suponer que basta una URL accesible. Si no puede obtener y verificar esos bytes, debe fallar sin omitirlos silenciosamente. Los enlaces externos, mapas integrados y destinos de formularios siguen siendo dependencias externas; portabilidad no implica funcionar todo sin conexión.
El contrato de confirmación de guardado
Durabilidad local y confirmación del servidor resuelven problemas distintos. Un borrador retenido permite recuperar en el mismo navegador. La confirmación establece la revisión utilizable por versiones y salidas del servidor. Un borrador local no garantiza que los mismos cambios estén disponibles en otro dispositivo.
La invariante importante es:
Una respuesta de guardado confirma una revisión concreta, no toda edición visible en el navegador.
Es un problema de concurrencia. Guardar tarda y el usuario puede seguir editando. Si al llegar la respuesta el sistema marca el estado como «sin cambios», puede mentir: hay cambios nuevos que no estaban en los datos enviados.
StackLiberate distingue trabajo pendiente de revisión confirmada. La confirmación se comprueba contra el estado enviado; una respuesta tardía no confirma cambios nuevos. Preparar archivos debe resolver envíos pendientes y obtener una revisión confirmada, o indicar que no puede continuar.
Este límite importa más que si el guardado fue automático o explícito. Una solicitud exitosa no prueba que todas las ediciones posteriores estén guardadas, y un borrador recuperable no sustituye la confirmación del servidor.
La exportación no es un sistema aparte
La exportación se vuelve frágil si intenta deducir un sitio de una sesión activa o mantiene su propia interpretación de los cambios.
En StackLiberate, exportar es una ruta de entrega del estado creado confirmado. No extrae del lienzo qué contenido o estilo pretendía el usuario:
Documento inicial validado + Cambios aceptados y ordenados + Recursos necesarios ↓ Revisión confirmada del sitio ↓ Comprobaciones de entrega y referencias portables ↓ Archivos de sitio estático (ZIP)La generación de archivos se ejecuta en el servidor sin necesitar un lienzo activo. La solicitud aún requiere acceso apropiado, revisión confirmada, recursos disponibles y configuración válida. Generar y entregar el archivo implica almacenamiento y red; no todo el servicio es una función pura.
El límite reproducible es el estado creado confirmado y sus entradas verificadas. Una versión restaurada puede convertirse en ese estado al terminar Restaurar; un borrador local arbitrario no es automáticamente lo que se exporta.
El sitio entregado usa HTML, CSS, JavaScript y recursos empaquetados estándar. No necesita el editor para renderizarse o alojarse en otro lugar. Los servicios de los que depende deliberadamente, como un destino externo de formulario, siguen siendo dependencias.
Consistencia por diseño, verificada con pruebas
Una representación compartida reduce dónde puede divergir el comportamiento. No hace equivalentes automáticamente los entornos de renderizado ni elimina defectos de implementación.
StackLiberate combina reconstrucción cronológica y revisiones explícitas con pruebas de proyecciones de navegador y servidor, versiones guardadas, estado restaurado y archivos estáticos. Se examinan documentos y recursos resultantes, no solo que una orden devolviera éxito.
Una capacidad completa necesita más que un control correcto en el lienzo. Los cambios aceptados deben sobrevivir a persistencia, reconstrucción y salidas pertinentes. Esto exige validar el cambio y cubrir con regresiones las proyecciones que lo consumen.
Las comprobaciones estructurales y de navegador responden preguntas distintas. Las primeras detectan orden incorrecto o recursos ausentes; las segundas revelan estilos aparentemente válidos sin efecto visible o diseños adaptables que se rompen.
El objetivo es contenido y comportamiento consistentes en los contextos admitidos, con diferencias intencionales comprendidas y fallos informados. No se afirma que haya píxeles idénticos en todo dispositivo ni que la divergencia sea imposible.
El ciclo de vida como un único recorrido
Un sitio de StackLiberate sigue un recorrido continuo desde creación, edición y versiones hasta vista previa y exportación:
- Creación: La plantilla elegida establece el documento inicial validado y sus recursos.
- Edición: Los cambios admitidos se validan, aceptan en orden y proyectan en el lienzo.
- Persistencia: Borradores locales y confirmación del servidor tienen funciones distintas; no se confunden cambios pendientes con estado confirmado.
- Versiones: Un punto guardado captura estado confirmado. Restaurar lo valida y establece una revisión actual nueva.
- Vista previa: El estado confirmado se materializa para revisión sin crear otra autoridad de edición.
- Exportación: El estado confirmado se materializa en archivos estáticos con recursos empaquetados verificados y referencias portables.
- Publicación: La ruta compartida de salida estática prepara los archivos para el despliegue.
En cada límite, el sistema debe identificar qué estado usa y verificar las entradas para reproducirlo. Un editor con trabajo pendiente nuevo no es la misma revisión que la última vista previa o exportación confirmada.
Ese límite explícito es el objetivo: autoridad compartida, materialización reproducible y comprobaciones donde difieren los contextos.
El editor y el alojamiento pueden evolucionar sin exigir que el sitio exportado conserve el entorno del editor. Su contenido y diseño se entregan como archivos web, en lugar de existir solo en una sesión de edición.