25 lines
2.8 KiB
Markdown
25 lines
2.8 KiB
Markdown
|
# Actualizaciones de la SPA
|
||
|
|
|
||
|
|
El HTML y las rutas de la SPA se sirven con `Cache-Control: no-cache`: el navegador puede guardarlos, pero debe revalidarlos antes de reutilizarlos. Los archivos existentes de `/assets/` tienen nombres con hash y se sirven con caché de un año e `immutable`. Los archivos que faltan en ese directorio devuelven 404, sin sustituirlos por HTML.
|
||
|
|
|
||
|
|
Cada build genera un identificador independiente de la versión de `package.json`, incluido tanto en JavaScript como en `version.json`. Las pestañas abiertas consultan ese archivo sin caché al inicio, cada minuto mientras están visibles y al recuperar el foco o la conexión. Una versión diferente muestra un aviso para guardar y recargar. Un fallo de importación dinámica de Vite muestra un aviso de recarga incluso si no es posible consultar la versión. No se recarga automáticamente ni se oculta el error original.
|
||
|
|
|
||
|
|
## Publicación
|
||
|
|
|
||
|
|
La configuración de Caddy debe aplicarse en producción para que las cabeceras tengan efecto. Si hay un proxy o CDN delante, debe respetar estas cabeceras y dejar de servir copias antiguas del HTML y `version.json`.
|
||
|
|
|
||
|
|
Actualmente `yarn build` del cliente borra `dist/client`, y Docker monta esa misma carpeta en Caddy. Compilar sobre la carpeta publicada provoca una ventana con archivos ausentes. Preparar el build en una carpeta de release separada, comprobarlo y publicar la release completa de forma atómica evita esa ventana.
|
||
|
|
|
||
|
|
La nueva release debe contener también los assets con hash de las releases anteriores durante el periodo en que se admitan pestañas abiertas (por ejemplo, varios días). Los assets se copian antes de publicar el HTML y `version.json` nuevos; nunca se sobrescribe un asset con hash con contenido distinto. El cambio atómico debe hacerse sobre una ruta visible para Caddy: sustituir solo un enlace o directorio en el host puede no actualizar un bind mount Docker existente. La mecánica concreta debe ajustarse al despliegue.
|
||
|
|
|
||
|
|
El aviso es una recuperación adicional, no sustituye la conservación de assets ni la publicación atómica. Una pestaña cargada antes de incorporar el monitor necesitará una primera recarga. Las cabeceras nuevas tampoco pueden invalidar por sí solas un HTML que ya tenga una caché vigente en un navegador o CDN.
|
||
|
|
|
||
|
|
## Comprobación en producción
|
||
|
|
|
||
|
|
- `/`, `/index.html` y `/quotes`: cabecera `Cache-Control: no-cache`.
|
||
|
|
- `/version.json`: JSON con `buildId` y cabecera `Cache-Control: no-store`.
|
||
|
|
- Un bundle existente en `/assets/`: `Cache-Control: public, max-age=31536000, immutable`.
|
||
|
|
- `/assets/inexistente.js`: 404, sin HTML de la SPA ni caché inmutable.
|
||
|
|
- Abrir una pestaña, publicar otra release y volver a la pestaña: aparece el aviso; al recargar se mantiene la URL y se carga la release nueva.
|
||
|
|
- Simular un fallo de carga de un módulo: aparece el aviso de recarga y no hay bucles de recarga automática.
|