Pull to refresh

Comments 8

Честно говоря, не уверен, что действительно стоит обновлять страницу сразу после деплоя: как минимум это плохо тем, что это вызовет шквал запросов от пользователя сразу после деплоя. Если деплой происходит часто, то это будет ещё и плохой user experience.


Также нужно учитывать, что у многих (большинства?) более-менее крупных сервисов есть ещё и мобильные клиенты, а иногда и десктопные тоже, и соответственно у вас должен быть более-менее стабильный API на стороне бэкенда, и соответственно, если вы из JS обращаетесь напрямую к этому API, то не обязательно перезагружать страницу пользователя принудительно. Понятно, что часто для веба делают ещё один слой между чистым API на бекенде и фронтендом, но даже в этом случае иметь некоторую обратную совместимость было бы тоже полезно.

{
  "autoReloadAfterUpdate": {
    "dev": true,
    "prod": false
  }
}
UFO just landed and posted this here
Пояснять нужно, куда добавлять-то?
а какое оптимальное решение тогда может быть?
на backend хранится версия. с фронта все запросы происходят с хедером 'HTTP_X_CLIENT_VERSION' = версия у клиента.
на backend смотрим версию в хедере запроса и если не совпадает с текущей — возвращаем код 418 с текущей версией. на фронте сохраняется версия из ответа и обновляется страница.
лучше не придумал пока
Делать обновление версии на бэке значительно проще, но это не всегда возможно. Суть моего решения в автономности фронта.
Например, если фронт не имеет бэка или если фронт может обновляться независимо от него.

Лучше использовать не дату сборки как идентификатор версии, а contenthash — хэш-строку на основе анализа содержимого файла, либо commithash — хэш последнего коммита. Это поможет избежать лишних срабатываний (при использовании балансера или пересборок).


Также рекомендую включать комментарий в каждый из итоговых js и css файлов с версией, пример для Webpack:


/**
 * @docs: https://webpack.js.org/plugins/banner-plugin
 *
 */

import webpack from 'webpack';

import pkg from '../../package.json';
import { env } from '../../env';

export const pluginBanner: webpack.WebpackPluginInstance = new webpack.BannerPlugin({
  banner: `@env ${env.NODE_ENV}:${pkg.version} @commit ${env.GIT_COMMIT}`,
  entryOnly: false,
});

Это позволит осуществлять дебаг без открытия доп. файла, узнавать у клиентов версии загруженных ресурсов (для решения проблем с кэшем, особенно актуально при использовании Service Worker), решить проблему с асинхронной загрузкой чанков (в случае, если их имена не модифицируются — можно в script.onload проверять совпадение версии в комментарии чанка и версии основного файла).


По поводу потери данных — можно определить интерактивные части (формы) и при обновлении версии фронтенда стор сохранять в Local Storage и восстанавливать после перезагрузки. Если меняется формат данных в сторе — то соответственно нужна схема миграции. Если компания нацелена на создание качественного продукта, это все несложно внедрить.


Да, и если есть SSR, то посылать информацию об обновлении файлов можно по сокету с ноды, а не методом опроса раз в минуту — выглядеть будет приятней, лишние запросы уйдут.

Спасибо, это вполне удобно, и делает процесс обновления вполне контролируемым.
Sign up to leave a comment.

Articles