此示例在本文稍后阅读有关构建过程时会引用此示例。当我们改善构建工具时，此过程的一些细节可能会发生变化，但这是当前的设计。

要上下文化并预览即将到来的部分，这是我们对此过程进行的扩展，以将PWA功能添加到应用程序平台中：

• 我们在步骤4 的启动的应用程序外壳中添加了一个服务工作者脚本
• 我们在步骤5 中与Web应用清单一起生成PWA清单
• 我们在步骤7中扩展了应用程序适配器，以支持几个客户端PWA功能
• 在步骤8 期间，App Shell中的服务工作者脚本被编译并添加到构建应用程序中

<link
    rel="manifest"
    crossorigin="use-credentials"
    href="%PUBLIC_URL%/manifest.json"
/>

但是，这些并不涵盖应用程序build目录中静态资产的全部；需要单独处理来自jQuery等供应商的图标，Web清单和JavaScript文件。为了将这些剩余的文件添加到Portache清单中，我们将另一个步骤添加到我们的 CLI的构建过程中。执行CRA构建步骤后，我们使用koude41函数从koude42软件包中读取App的build目录中的所有其他 static文件，生成这些URL的清单，并注入 在准备好的占位持有人的汇编服务工作者中列表。您可以看到生成的injectManifest代码here。

正确处理这些止痛药的表现对于保持应用程序的最新时间也很重要，这将在下面的"Managing the service worker's updates and lifecycle" section中进行描述。

为了实现PWA功能的选择加入性质，只有在应用程序的configuration中启用PWA时才能注册服务工作者。我们在koude24 app config file中添加了一个可以启用PWA的选项，看起来像这样：

// d2.config.js
module.exports = {
    type: 'app',
    title: 'My App',

    // Add this line:
    pwa: { enabled: true },

    entryPoints: {
        app: './src/App.js',
    },
}

在d2-app-scripts start或build流程中，读取配置文件，并将PWA_ENABLED值添加到应用程序的环境变量中。然后，在应用程序适配器的初始化逻辑中，它根据PWA_ENABLED环境变量进行注册或注册服务工作者。

在下面的"Registration of the service worker"部分中更详细地描述了注册逻辑。

管理服务人员的更新和生命周期

管理服务人员的lifecycle既复杂又至关重要。由于服务工作者负责从缓存文件提供该应用程序，因此现在它在用户看到的应用程序中具有哪些角色。请注意，服务工作者从编译时设置的文件列表中为该应用提供服务。因此，服务工作者本身需要在用户的浏览器中进行更新，以便为应用程序的更新版本提供。

如果服务工作者生命周期和更新的管理不善，则该应用程序可能会粘在用户浏览器中的旧版本上，并且永远不会从服务器接收更新。这可能很难诊断，很难解决。下面的"Handling precached static assets between versions" section解释了为什么会发生这种情况。

管理PWA更新可能是一个著名的问题，我们认为我们已经遇到了一个可靠的系统来处理它，我们将在下面描述。

设计一个良好的用户体验以更新PWA应用程序

从UX角度来看，管理服务工作者更新很复杂：我们希望用户使用该应用程序的最新版本，但是更新服务工作者以激活生产中的新应用更新需要页面重新加载，由于下面描述的原因。重新加载可能会导致页面上未保存的数据丢失，因此未经用户同意，我们不想这样做。因此，它提出了UX设计挑战，以通知和说服用户重新加载应用程序尽快使用新更新，同时避免使用任何危险的，计划外的页面重新加载。

更重要的是，我们希望以最不可能的方式做到这一点，理想情况下，没有用户需要考虑任何技术。诸如“可用更新”之类的通知会太侵入性，甚至对某些用户看起来可疑。

要解决这些需求，我们解决的UX设计是：

1. 首先，如果服务工作者已经安装并且已经准备就绪，我们将不会立即激活它。我们将拭目以待，并尝试在不需要做任何事情的情况下潜行更新。接下来发生的事情取决于一些条件。
2. 如果这是服务工作者第一次为此应用程序安装，那么任何页面重新加载都将利用已安装的服务工作者，并且PWA功能将在该重新加载的页面中准备就绪。如果打开多个选项卡，则每个选项卡都需要重新加载才能使用服务工作者和PWA功能。
3. 如果新安装的服务工作者是对现有的服务工作者的更新，但是重新装载将不会自动激活等待服务的工作者。
   1. 如果此应用程序只有一个选项卡，那么下次用户加载页面时，可以在更新中安全潜行。在加载应用程序的主要交互部分之前，App Shell检查了等待服务的工作人员，如果有一个，则将其激活，然后重新加载，因此可以安全地更新服务工作者而不会干扰用户的活动。
   2. 如果用户具有应用程序的多个选项卡，但是，我们将无法快速更新和重新加载。这是因为Active Service Worker同时控制所有活动选项卡，因此要激活新的服务工作者，需要同时重新加载所有选项卡。在未经用户权限的情况下重新加载所有选项卡可能会在其他打开选项卡中丢失未保存的数据，因此我们不想这样做。在这种情况下，我们依靠接下来的选项发生。
4. 如果安装了新的服务工作者并等待接管，则在用户个人资料菜单的底部可见通知。如果他们单击它，将指示等待服务的工作人员接管，并且页面将重新加载。 如果有多个打开的选项卡，将显示所有选项卡都将重新加载，以便在继续之前保存这些选项卡中的数据。如果可能的话，在模式中显示了选项卡的数量，以帮助用户帐户遗忘的选项卡，如果用户打开了许多浏览器窗口或在移动设备上，则可能发生。
5. 如果以上情况都没有发生，则该应用将依靠本机浏览器行为：在该浏览器中的应用程序的所有打开选项卡已关闭后，新的服务工作者将在下次打开应用程序时处于活动状态。

我们还在努力实施以改进此UX：

1. 当新服务工作者在等待时，将在标题栏中的用户配置文件图标上显示徽章，以表明有新信息可以检查
2. 在任何服务工作者控制该应用程序之前，标题栏中的某些UI元素将表明尚不可用的PWA功能

应用程序更新流的实现

在应用程序平台中实现此更新流，需要几个合作的功能和许多在服务工作者代码，客户端服务工作者注册功能和React用户界面中的幕后逻辑。

为了简化与navigator.serviceWorker API的反应环境中与服务工作者的沟通，我们制作了一个Offline Interface object，该Offline Interface object处理基于事件的服务与服务工作者的通信，并揭示了更易于使用的注册和更新操作的方法。它还提供了一些功能，可提供可缓存的部分和复杂的离线功能，这些功能将在后续PWA博客文章中进行详细描述。

我们的服务工作者注册功能从创建React App PWA模板registration boilerplate中得出了很多，其中包括一些有用的逻辑，例如检查有效的服务工作者，处理LocalHost上的开发情况以及一些基本的更新检查程序。这些功能是一个有用的起点，但是我们的用例需要更加复杂，这导致了下面描述的详细说明。

服务工作人员的注册

如果启用了PWA，则当应用程序加载时，当离线接口对象为instantiated in the App Adapter时，koude52 function是called。在调用window对象上的load事件的register()函数之前，请致电navigator.serviceWorker.register()以提高页面加载性能：注册后的浏览器检查新服务工作者的检查，如果有一个，如果有一个，服务工作者将下载并安装任何需要的应用程序资产，则需要art。这些下载可能是资源密集的，因此它们会延迟以避免在第一次加载时干扰页面响应。

离线接口也是registers a listener到navigator.serviceWorker上的controllerchange事件，该事件将在新服务工作者控制时重新加载页面，即开始处理提取事件。这是为了确保应用程序使用最新的刻板资产加载。

与某些实施不同，我们的服务人员旨在耐心等待它安装。首次安装和激活后，它不会索取开放客户端，即控制这些页面并通过使用clients.claim() API开始处理提取事件；相反，它在控制之前等待页面重新加载。该设计可确保页面仅在其一生中由一个 服务工作者或 none 控制。服务工作者需要重新加载来控制以前未受控制或从上一个页面接管页面的页面。这确保该应用仅使用该应用程序的一个版本中的核心脚本和资产。服务工作者也不会自动 skip等待，并在安装新更新后控制页面；它将继续等待来自应用程序的信号或part 4 of the UX flow above中描述的默认条件。服务工作者做的做法是listen for messages从客户端指示要求客户或跳过等待的客户，然后发送的用户单击“配置文件”菜单中的“单击重新加载”选项。听众看起来像这样：

self.addEventListener('message', (event) => {
    if (event.data.type === 'CLAIM_CLIENTS') {
        // Calls clients.claim() and reloads all tabs:
        claimClients()
    }
    if (event.data.type === 'SKIP_WAITING') {
        self.skipWaiting()
    }
})

'CLAIM_CLIENTS'首次为此应用程序安装了服务工作者时使用，并且在安装更新的服务工作者并准备接管时使用'SKIP_WAITING'。下面您可以看到有关这些消息的更多详细信息。

尽可能自动应用应用更新

在大多数情况下，koude62组件使应用程序可以在页面加载时在应用程序更新中潜行，而无需用户需要知道或做任何事情。它是implemented in the App Adapter，并由离线接口支持。它包装了应用程序的其余部分，在将其下方的组件树呈现之前，它检查是否有新的服务工作者正在等待接管。如果有一个，并且仅打开了一个选项卡，则可以指示新服务工作者在加载应用程序之前接管。这允许应用程序安全地更新和重新加载，而不会干扰用户的工作。

export const PWALoadingBoundary = ({ children }) => {
    const [pwaReady, setPWAReady] = useState(false)
    const offlineInterface = useOfflineInterface()

    useEffect(() => {
        const checkRegistration = async () => {
            const registrationState =
                await offlineInterface.getRegistrationState()
            const clientsInfo = await offlineInterface.getClientsInfo()
            if (
                (registrationState === REGISTRATION_STATE_WAITING ||
                    registrationState ===
                        REGISTRATION_STATE_FIRST_ACTIVATION) &&
                clientsInfo.clientsCount === 1
            ) {
                console.log(
                    'Reloading on startup to activate waiting service worker'
                )
                offlineInterface.useNewSW()
            } else {
                setPWAReady(true)
            }
        }
        checkRegistration().catch((err) => {
            console.error(err)
            setPWAReady(true)
        })
    }, [offlineInterface])

    return pwaReady ? children : null
}

渲染后，加载边界首先使用离线接口的getRegistrationState()方法（一种访问koude63 registration function的便利方法）首先检查任何新服务工作者。 getRegistrationState()是服务工作者的安装状态的简化检查，旨在确定现在是否准备好新服务工人。它返回几个值之一：'UNREGISTERED'，'WAITING'如果已经准备好更新的服务工作者，则'FIRST_ACTIVATION'如果这是第一次安装服务工作者，或者'ACTIVE'如果已经有控制的服务工作者，并且当前没有一个服务工人。

然后，要检查该应用程序的打开数量，PWALoadingBoundary使用了离线接口的koude71 method，它“询问” Ready Service Service Worker与此服务工作者范围相关联的客户有多少客户。为了在每种情况下准确获取此信息，服务工作者需要进行perform some special checks，如下所示。

/** Get all clients including uncontrolled, but only those within SW scope */
export function getAllClientsInScope() {
    // Include uncontrolled clients: necessary to know if there are multiple
    // tabs open upon first SW installation
    return self.clients
        .matchAll({
            includeUncontrolled: true,
        })
        .then((clientsList) =>
            // Filter to just clients within this SW scope, because other clients
            // on this domain but outside of SW scope are returned otherwise
            clientsList.filter((client) =>
                client.url.startsWith(self.registration.scope)
            )
        )
}

服务工作者将koude72 API与includeUncontrolled选项一起使用，因为在服务工作者第一次安装时，某些选项卡可能无法控制。然后，由于该功能返回该域上的每个打开客户端，甚至在服务工作者控制范围之外的范围之外，因此所得的客户端需要将其过滤至范围中的客户端。服务工作者获取正确的客户端列表后，它将一条消息发给客户端以报告客户端信息。然后，getClientsInfo()方法返回一个承诺，该承诺要么解决客户信息，要么以失败原因拒绝。

如果有一个服务工作者正在等待接管（上面的'WAITING'或'FIRST_ACTIVATION'条件），并且应用程序打开了一个选项卡，PWALoadingBoundary将通过在离线接口上调用koude78 method来应用Ready更新。该方法指示新的服务工作者接管：â€检测到该新服务工作者是为此应用程序安装的第一个或对现有服务工作者进行更新的工作人员，然后将'CLAIM_CLIENTS'消息发送到第一个安装服务工人或'SKIP_WAITING'消息给更新的服务工作者。跳过服务工作者的等待或要求客户端的客户都会在Open客户端中导致a的controllerchange事件，这触发了活动的侦听器，该活动的侦听器在navigator.serviceWorker上设置了聆听该事件（从"Registration of the service worker"部分中召回）。然后，侦听器将致电window.location.reload()重新加载页面，以便该页面可以在新服务工作者的控制下加载。

如果没有新的服务工作者或打开多个选项卡，则应用程序的其余部分将按照普通状态加载。通过加载应用程序之前进行此检查，该应用程序可以应用PWA更新，而无需用户在大多数情况下需要做任何事情，这对于用户体验来说是一个不错的胜利。

为手动应用更新提供UI

koude84 hook提供了支持UI手动应用更新的逻辑，而koude85 component将钩子连接到相关的UI组件。像PWALoadingBoundary组件一样，挂钩和ConnectedHeaderBar组件在应用程序适配器中实现，并由离线接口支持。两者的代码如下所示 - 仔细查看usePWAUpdateState Hook的onConfirmUpdate()函数，confirmReload()函数和useEffect()钩。

export const usePWAUpdateState = () => {
    const offlineInterface = useOfflineInterface()
    const [updateAvailable, setUpdateAvailable] = useState(false)
    const [clientsCount, setClientsCount] = useState(null)

    const onConfirmUpdate = () => {
        offlineInterface.useNewSW()
    }
    const onCancelUpdate = () => {
        setClientsCount(null)
    }

    const confirmReload = () => {
        offlineInterface
            .getClientsInfo()
            .then(({ clientsCount }) => {
                if (clientsCount === 1) {
                    // Just one client; go ahead and reload
                    onConfirmUpdate()
                } else {
                    // Multiple clients; warn about data loss before reloading
                    setClientsCount(clientsCount)
                }
            })
            .catch((reason) => {
                // Didn't get clients info
                console.warn(reason)

                // Go ahead with confirmation modal with `0` as clientsCount
                setClientsCount(0)
            })
    }

    useEffect(() => {
        offlineInterface.checkForNewSW({
            onNewSW: () => {
                setUpdateAvailable(true)
            },
        })
    }, [offlineInterface])

    const confirmationRequired = clientsCount !== null
    return {
        updateAvailable,
        confirmReload,
        confirmationRequired,
        clientsCount,
        onConfirmUpdate,
        onCancelUpdate,
    }
}

export function ConnectedHeaderBar() {
    const { appName } = useConfig()
    const {
        updateAvailable,
        confirmReload,
        confirmationRequired,
        clientsCount,
        onConfirmUpdate,
        onCancelUpdate,
    } = usePWAUpdateState()

    return (
        <>
            <HeaderBar
                appName={appName}
                updateAvailable={updateAvailable}
                onApplyAvailableUpdate={confirmReload}
            />
            {confirmationRequired ? (
                <ConfirmUpdateModal
                    clientsCount={clientsCount}
                    onConfirm={onConfirmUpdate}
                    onCancel={onCancelUpdate}
                />
            ) : null}
        </>
    )
}

通过使用一个空依赖性阵列的useEffect钩，首先渲染时，usePWAUpdateState钩子通过调用离线接口的checkForNewSW()方法来检查新服务工作者，这基本上只是暴露了koude95 registration function。与PWALoadingBoundary使用的getRegistrationState()函数相比，checkForUpdates()更为复杂，因为它检查了安装和准备就绪的服务工作人员，请听取新的服务，并检查这些州之间的服务工作人员。我们需要检查许多变量以处理所有可能的安装条件：

• 服务工作者可以是其生命周期的四个步骤之一：安装，安装，激活或激活
• 可以同时在service worker registration object中以installing，waiting或active同时存在多个服务工作者
• 有时，活动服务工作者不在 Control 中，因为它是此应用程序的第一个服务工作者安装

对于完整的控制流，请看一下checkForUpdates() source code。

如果有是准备了新服务，则称为onNewSW()回调函数，作为向checkForNewSW()的参数提供的回调函数，该函数将hook返回的updateAvailable布尔人设置为true。 ConnectedHeaderBar组件将此值作为道具传递给标头键，该键显示“可用的新应用版本”在用户配置文件菜单中的通知。

如果用户打开配置文件菜单并单击“可用新版本”通知，则调用confirmReload()函数。它通过检查该应用程序的多少个选项卡，以处理更新流的下一部分，以便如果打开多个选项卡，可以向警告显示它们将全部重新加载。像PWALoadingBoundary一样，它使用离线接口的getClientsInfo()方法来获取与此服务工作者关联的客户次数。

收到客户端信息后，如果为此服务工作者范围打开一个客户端，confirmReload()将使用离线接口的koude78 method来指示新服务工作者像PWALoadingBoundary一样控制控制。如果有多个客户端打开，或者getClientsInfo()请求失败，则confirmationRequired布尔人由usePWAUpdateState Hook返回的Boolean将解析为true。在ConnectedHeaderBar组件中，这将导致渲染ConfirmReloadModal警告当所有打开选项卡都重新加载时数据丢失。

如果用户单击模式中的“重新加载”，则称为onConfirmUpdate()函数，该功能称为offlineInterface.useNewSW()函数并触发更新。如果用户单击“取消”，则称为onCancelUpdate()函数，将confirmationRequired布尔值重置为false，通过将clientsCount设置为null，它将关闭模式。

引擎盖下的所有这些步骤均已协调以创建强大的user experienc described above，并确保服务工作者和应用程序正确更新。

处理版本之间的静态资产

如上所述的"Compiling the service worker" section中所述，在使用App Assets的孔道上时，应在App和Service Worker更新方面正确处理多个注意事项。方便地，这些最佳实践由Wookbox工具（WebPack插件和workbox-build软件包）处理。

使用曲折策略时，即使服务器上有新版本的应用程序，应用程序可能会陷入用户客户端的旧版本。由于不访问网络的不访问网络的情况将直接从高速缓存提供，因此在服务工作者本身更新，下载新的资产并为其服务之前，新应用更新将永远不会访问。

要使服务工作者更新，服务器上的脚本文件需要从客户端上运行的同名文件的文件（在我们的情况下）差异（在我们的情况下） 。浏览器检查服务工作者范围中导航事件或调用navigator.serviceWorker.register功能时的导航事件时，将检查服务工作者的更新。为了确保服务器上的应用程序中的更新最终在客户端的浏览器中，修订Info 在服务工作者的potache清单中的文件名中添加到文件名中，如果该文件名还没有。当更改应用程序文件时，内容哈希将在portache清单中更改，因此service-worker.js文件的内容将不同。

/** Called if the `pwaEnabled` env var is not `true` */
export function setUpKillSwitchServiceWorker() {
    // A simple, no-op service worker that takes immediate control and tears
    // everything down. Has no fetch handler.
    self.addEventListener('install', () => {
        self.skipWaiting()
    })

    self.addEventListener('activate', async () => {
        console.log('Removing previous service worker')
        // Unregister, in case app doesn't
        self.registration.unregister()
        // Delete all caches
        const keys = await self.caches.keys()
        await Promise.all(keys.map((key) => self.caches.delete(key)))
        // Delete DB
        await deleteSectionsDB()
        // Force refresh all windows
        const clients = await self.clients.matchAll({ type: 'window' })
        clients.forEach((client) => client.navigate(client.url))
    })
}