Большинство веб-страниц, которые я создал, основаны на идее, что люди приходят, делают свои дела, а затем уходят. Этот процесс повторяется каждый раз, когда им нужны функции, предоставляемые сайтом, будь то инвестиционная платформа, электронный магазин или какой-либо инструмент администрирования.
Но что, если пользователи никогда не уходят? Что, если они будут держать страницу открытой 24/7, без обновления, повторного входа или повторного входа на сайт. Представьте себе мониторинг компьютеров на заводах или в больших складских помещениях. У них есть отдельные машины только для этой единственной вещи, которая будет храниться на странице навсегда, поскольку эта единственная страница является единственной целью компьютера.
Помимо всевозможных других проблем или проблем, которые могут возникнуть, сегодня мы поговорим о следующем: «Как мы можем быть уверены, что пользователи используют последнюю версию сайта?»
Часто используется уловка - ставить метку времени для ваших файлов каждый раз, когда вы их меняете. Это заставит браузеры аннулировать кеш и повторно загрузить файлы, и, таким образом, все люди, которые зайдут на сайт после развертывания, получат новую версию ваших файлов. Всегда будут пользователи, которые оставили страницу открытой и будут использовать старую версию в течение короткого времени, но обычно это не является большой проблемой, особенно при работе с сайтами, на которых пользователи проводят 2–10 минут.
Но в нашем случае мы имеем дело с пользователями, которые теоретически никогда не будут перезагружать index.html, поэтому даже если временные метки или хэши файлов изменятся, они никогда не узнают об этом.
Итак, что собираетесь делать?
- Мы будем хэшировать имена файлов при каждой сборке, чтобы знать, когда они изменились.
- Мы создадим version.json в нашей папке dist, которая содержит хэш текущей сборки, а также введем хеш текущей сборки в сам код.
- Мы заставим интерфейс опрашивать version.json каждые X минут, чтобы проверять, изменился ли хеш по сравнению с его «внутренним» хешем.
- Если это так, мы перезагрузим клиент либо принудительно, либо изящно, предоставив всплывающее / другое уведомление о новой версии.
Обратите внимание, что хотя в этом посте мы сделаем это для Angular 4, он никоим образом не привязан к Angular или какой-либо из его конкретных версий и может быть реализован во всех SPA.
При сборке проекта Angular 4 с angular-cli и производственным флагом он автоматически хэширует файлы, поэтому первая часть покрывается их конфигурацией веб-пакета по умолчанию. Все, что вам нужно сделать, это: ng build --prod и в вашей /dist/ папке будет куча файлов, одним из которых будет /dist/main.somehash.bundle.js. Это тот файл, о котором мы заботимся, поскольку он содержит все наши собственные JS. Есть и множество других файлов, которые генерируются в процессе сборки, но мы сосредоточимся на main.js.
Для второго пункта я создал /build/post-build.js файл:
Этот файл запускается после сборки angular, поэтому наша команда производственной сборки в настоящее время выглядит примерно так npm build && npm run build --prod && npm run post-build
пост-сборка - это просто сценарий в нашем package.json: "post-build": "node ./build/post-build.js"
После запуска этого скрипта у вас должен быть version.json в /dist/folder примерно так:
И третья и четвертая части идут вместе, поэтому у нас будет version-check.service.ts, который обрабатывает логику опроса и принудительного обновления клиента.
Это импортировано в app.components.ts, а в ngOnInit мы называем versionCheckService.initVersionCheck(environment.versionCheckURL);
Вот и все. Теперь всякий раз, когда вы выполняете развертывание, в version.json будет изменяться хэш, и пользователи будут уведомлены после того, как они опросят файл версии. Вы можете уменьшить интервал опроса, если критически важно, чтобы все пользователи использовали последнюю версию, или дольше, если это не так. Вы также можете включить кучу другой информации в version.json, если вам нужно, например, контролировать, является ли это развертывание критическим или нет, и переключаться между принудительным и плавным обновлением с использованием этой информации.
