Notas de ingeniería · Arquitectura
Tiempo de lectura · 9 min
Construir un editor visual alrededor de código portable
Cómo el renderizado aislado, la identidad estable y las operaciones validadas separan los mecanismos del editor de los archivos web portables.
Los editores visuales tienden naturalmente a entrelazarse con las páginas que modifican.
El editor inserta marcadores de selección, registra escuchas de eventos, envuelve elementos en contenedores para calcular posiciones y añade atributos, anotaciones y ajustes de estilo para la edición.
Nada de eso pertenece al sitio terminado.
Cuando la instrumentación de edición se mezcla con el estado creado del sitio, separarla de los archivos entregados se vuelve más difícil al añadir capacidades.
StackLiberate separa el documento inicial, los cambios aceptados y los recursos necesarios de los mecanismos para editarlos. El lienzo es una proyección de ese estado. Una capa de comunicación conecta la aplicación de edición con la página renderizada sin convertirla en la autoridad de los cambios guardados.
El editor existe alrededor del código. No vive dentro de él.
El límite del iframe es arquitectónico, no cosmético
El editor de StackLiberate renderiza el sitio en un iframe aislado de otro origen. Así separa la aplicación de edición del documento y el entorno JavaScript de la página, en lugar de limitarse a evitar colisiones de CSS.
La aplicación principal se comunica con el iframe mediante un puente de mensajes estructurado. Las solicitudes describen acciones como localizar un objetivo, medir sus límites o aplicar una proyección visual. Las respuestas informan observaciones o finalización.
Los mensajes deben provenir del iframe y origen esperados. Las respuestas también deben corresponder a la solicitud que se completa. Que llegue un mensaje no prueba por sí mismo que la edición actual se haya aplicado correctamente.
El límite hace explícito y comprobable el trabajo entre marcos. No impide automáticamente efectos secundarios ni hace fiable cada mensaje; ambos lados siguen necesitando validación y gestión del ciclo de vida.
El puente conecta la intención de edición con la página
El puente es código específico del editor instalado en el documento del lienzo. Conecta solicitudes de edición y observaciones de página; no es el entorno público del sitio.
No es el único JavaScript permitido en el iframe. Las plantillas validadas pueden incluir scripts admitidos de navegación, animación y otros comportamientos compatibles. Esas interacciones públicas deben distinguirse de las herramientas de selección y órdenes de edición.
Cumple varias funciones:
- Escucha eventos del puntero e informa a la aplicación principal de la identidad del elemento.
- Permite indicar selección y elemento señalado sin convertir esos efectos en cambios del contenido del sitio.
- Ejecuta consultas DOM para la aplicación principal: leer texto, calcular límites y enumerar elementos.
- Aplica proyecciones de cambios para mostrar las ediciones en tiempo real.
- Informa la posición de desplazamiento y las dimensiones de la vista para alinear controles superpuestos.
Aplicar una proyección cambia necesariamente el DOM activo. Es distinto de aceptar una edición persistente. El puente gestiona el trabajo del navegador; el estado de edición y los límites de persistencia determinan qué cambios pertenecen al sitio y su historial.
Una actualización visual exitosa es solo parte de la operación. La validación del objetivo, el estado aceptado y la proyección correspondiente deben coincidir antes de considerar completo el resultado.
La identidad estable permite la edición estructurada
Un editor que registra cambios como «reemplazar el innerHTML del nodo en esta ruta DOM» es frágil.
Las rutas se rompen al reordenar secciones. Los índices cambian al añadir elementos repetibles. Los selectores encuentran otros elementos cuando cambia la estructura para diseños adaptables.
StackLiberate conserva identidades estables para las superficies editables. Atributos como data-sl-id conectan elementos físicos con sus objetivos lógicos. La identidad no depende de la posición actual del elemento y un identificador no concede por sí solo permiso para editarlo.
Un cambio aceptado debe dirigirse al objetivo apropiado y sus capacidades admitidas. Si falta el objetivo o es incompatible, seleccionar otro nodo mediante una alternativa cómoda no sustituye la validación.
Esto significa:
- La reconstrucción conserva las identidades usadas por los cambios aceptados.
- Mover una sección ajena no redefine la identidad de un elemento.
- Los elementos duplicados reciben identidades distintas, sin compartir los objetivos del original.
- Restaurar comprueba los cambios contra el origen y los recursos de la versión guardada.
- La generación de archivos usa objetivos validados en lugar de deducir intención del texto visible.
La identidad estable permite edición estructurada; no es por sí misma un límite de seguridad. Lo que permite un objetivo se determina por separado de que un elemento tenga un atributo de edición.
Operaciones aceptadas y cambios proyectados tienen funciones distintas
Una acción del usuario se acepta como una operación estructurada con objetivo definido, datos admitidos y estado previo esperado. Una operación puede afectar varias partes del documento: duplicar una tarjeta puede crear juntos objetivos de texto, imágenes, enlaces e iconos.
Los cambios parciales siguen siendo útiles como instrucciones derivadas para actualizar un documento. Por sí solos no son el registro autoritativo completo. Una acción aceptada puede producir varios pasos de proyección y seguir siendo una unidad de Deshacer.
La distinción es:
- Intención: el cambio admitido que solicita el usuario.
- Operación aceptada: el cambio validado conservado como parte del estado ordenado del sitio.
- Proyección: las actualizaciones del documento necesarias para presentar ese estado en un contexto concreto.
El documento inicial permanece separado de las ediciones posteriores. Reconstruir el sitio creado requiere sus cambios aceptados y los recursos para interpretarlos:
documento inicial validado + cambios aceptados y ordenados + recursos necesarios → estado creado → proyección del documento para cada contextoEsto tiene varias consecuencias para la portabilidad:
Reconstrucción cronológica. Cada operación se evalúa contra el estado producido por las anteriores aceptadas, no contra un diseño final ajeno.
Edición no destructiva. Deshacer, Rehacer y restaurar versiones operan sobre estado conservado. No necesitan adivinar qué significaba una página renderizada antes ni ofrecen al usuario reordenar arbitrariamente el historial de operaciones.
Cambios acotados. La validación en ejecución comprueba qué permite un objetivo y qué expresa la operación solicitada. Los tipos estáticos ayudan al desarrollo, pero no sustituyen la validación de solicitudes o contenido entrantes.
Independencia de la exportación. La materialización en el servidor reconstruye el estado confirmado y empaqueta sus recursos. No necesita inspeccionar un lienzo activo del editor.
La validación protege los límites del estado y la entrega
Un mensaje bien formado no es necesariamente una edición válida. La entrada puede contener contenido no admitido, dirigirse a un objetivo no disponible o describir un cambio basado en un estado que ya no es actual.
La validación debe responder preguntas separadas:
- Validez de la solicitud: ¿se admite la operación y están bien formados sus datos?
- Autoridad para editar: ¿tiene acceso el usuario actual y permite este objetivo el cambio?
- Validez del estado: ¿cumplen las reglas de la operación el estado previo esperado y el candidato resultante completo?
- Preparación para la entrega: ¿se pueden materializar de forma segura el sitio confirmado y sus recursos para los archivos solicitados?
Son responsabilidades de distintos límites, no una única pasada universal de saneamiento. Rechazar una transición inválida no es lo mismo que limpiar un fragmento o quitar instrumentación de edición de un archivo de salida.
El objetivo es aceptar solo cambios admitidos e informar fallos en lugar de construir silenciosamente un sitio distinto. Se necesitan pruebas de entradas inválidas, estado obsoleto, reconstrucción y entrega junto a esas comprobaciones.
El editor ve una proyección, no la verdad
Lo que ve el usuario en el lienzo no es idéntico a lo que se exportará.
La vista del editor incluye:
- Resaltados de selección en el elemento actual.
- Indicadores al pasar el puntero que muestran objetivos editables.
- El propio script del puente.
- Proyecciones de cambios locales aún no confirmados en el servidor.
- Direcciones de entrega de recursos adecuadas para la sesión de edición.
El sitio exportado no incluye nada de eso.
La diferencia es deliberada. La información de edición pertenece al lienzo, no al sitio creado. Un editor con cambios locales nuevos debe distinguirse de la exportación de la última revisión confirmada; comparar ambos estados no es probar la paridad de salida.
El contrato de paridad es:
Para una misma revisión confirmada, las proyecciones deben preservar contenido, estructura, diseño, identidad de recursos, navegación, orden y visibilidad de secciones.
Se excluyen la instrumentación de edición y la selección temporal. Las diferencias de entrega intencionadas, como un acordeón cerrado al inicio para visitantes, deben preservar el contenido subyacente. Las pruebas estructurales y de navegador verifican los resultados; compartir modelo no demuestra por sí solo equivalencia.
Por qué importa para la portabilidad
El sitio exportado no necesita el puente, las herramientas de selección ni el entorno de la aplicación del editor. Se eliminan de los archivos entregados.
Eso no significa quitar el comportamiento del sitio. Se mantienen scripts públicos de menús e interacciones admitidas. Un mapa puede seguir usando un iframe y un formulario un destino externo. Portabilidad significa independencia del editor, no ausencia de JavaScript o servicios externos.
La exportación materializa en el servidor el estado creado confirmado, verifica recursos empaquetados obligatorios, reescribe referencias portables y genera archivos estáticos. Un alojamiento compatible puede servir el HTML, CSS, JavaScript y archivos multimedia estándar sin ejecutar el editor visual.
Así la portabilidad es un requisito del diseño de capacidades, no una limpieza aplazada hasta la descarga. Una función completa necesita operaciones válidas, reconstrucción duradera y comportamiento apropiado en vista previa y archivos finales.
La arquitectura aporta límites comunes; las pruebas de regresión comprueban que sigan coincidiendo al evolucionar las capacidades.
Esa disciplina es el costo de construir un editor visual que no se convierta en parte del sitio que edita.