An Angular field-inspection app must start and show assigned inspections with no signal; how would you configure @angular/service-worker, and what can it not do for offline submissions?
answer
- must be installed while online
- prefetch every chunk
- freshness with a short timeout
- reference data cache-first
- writes need the app's own queue
basics
~20 sPrefetch all app code, cache inspections in a freshness dataGroup with a short timeout and long maxAge, cache reference data with performance, and make sure the worker installs before going offline; submissions still need an app-level queue.
solid answer
~40 sThe worker only helps after it has installed a full version, so inspectors must open the app online once; the default `registerWhenStable:30000` strategy can delay registration, so `registerImmediately` is worth considering. Keep the `app` asset group on `prefetch` so every lazy chunk is available offline, and prefetch or lazily cache the icons the forms need. Add `dataGroups`: assigned inspections with `freshness`, a timeout of a few seconds and a `maxAge` longer than the longest trip; checklist templates with `performance`, a long `maxAge` and `refreshAhead`. Cap every group with `maxSize`. The service worker caches only `GET` and `HEAD`, so a `POST` of results fails offline: the app must store pending submissions itself and resend them later. Use `SwUpdate` to prompt for reloads only between inspections.
go deeper
Recall that the service worker caches app files for offline start and that API data needs dataGroups.
Explain which asset and data group settings make the app and its inspection list available offline.
Design the full offline path: installation timing, strategies per endpoint, an app-level outbox, and safe update prompts.
Decide what data may be cached on field devices, how long offline work may diverge from the server, and who owns sync conflicts.
## The requirements Inspectors drive to sites with no mobile signal. On site they must be able to **start the app**, **see their assigned inspections**, **fill checklists** and **record results**. Results reach the server when they are back in coverage. `@angular/service-worker` covers most of the read side; the write side needs application code. ## Step 1: make sure a complete version is installed A service worker only serves what it has cached. Two consequences: - The inspector must open the app **online at least once** after each release, long enough for the worker to register and cache a full version. - `provideServiceWorker()` defaults to `registrationStrategy: 'registerWhenStable:30000'`: register when the app becomes stable, at most 30 seconds after start. For this app, `'registerImmediately'` (or a short `registerWithDelay:<ms>`) reduces the chance that someone opens the app briefly in the depot and leaves before registration. ```ts provideServiceWorker('ngsw-worker.js', { enabled: !isDevMode(), registrationStrategy: 'registerImmediately', }); ``` ## Step 2: asset groups for offline start - Keep the **`app`** group on **`installMode: prefetch`** with `/*.js` and `/*.css`, so every lazy route chunk, including rarely used inspection types, is cached with the version. - Put form icons and images in a group with **`lazy`** install and **`prefetch`** update, or `prefetch` install if the set is small and every form needs them. ## Step 3: data groups for API reads The generated config has **no `dataGroups`**, so without this step the inspections list is not available offline at all. | Data | Strategy | Settings and reasoning | |---|---|---| | Assigned inspections `/api/inspections/**` | `freshness` | `timeout` of a few seconds so a weak signal falls back to cache quickly; `maxAge` longer than the longest trip; `maxSize` bounded | | Checklist templates and reference lists | `performance` | Long `maxAge`, `refreshAhead` so aging entries refresh in the background; changes are rare | | Anything per-request and sensitive | none | Not cached; decide explicitly what may live on a shared tablet | Order groups from specific to broad; the first match wins. Bump a group's `version` when the API response format changes incompatibly, so old entries are discarded. ## Step 4: what the service worker cannot do - **Writes are not cached or queued.** Only `GET` and `HEAD` go through the cache. A `POST` or `PUT` to a matching URL removes that URL's cached entry and is sent to the network; offline it fails, with the worker returning an error status such as `504`. - The app therefore needs its **own outbox**: store each submission locally (for example in IndexedDB), show it as pending, and resend when requests succeed again. Because `freshness` falls back to cached data, the app should also merge pending local results over the cached inspection list, or the inspector will see completed work as still open. - **Photos taken on site** are data the app stores and uploads itself; they are not assets. ## Step 5: updates without disrupting work - Subscribe to `SwUpdate.versionUpdates` and prompt on `VERSION_READY` **only when no inspection is in progress**. - Avoid `activateUpdate()` without a reload; a mismatched lazy chunk in the field, with no signal, is unrecoverable until the inspector is back online. - Handle `SwUpdate.unrecoverable` by telling the user to reload when connected. ## Rollout checklist 1. Confirm the `app` group covers every emitted JavaScript and CSS file. 2. Add the inspection and reference `dataGroups`, each with a bounded `maxSize`. 3. Switch the registration strategy and verify the worker registers on a short visit. 4. Build the local outbox and the merge of pending results over cached data. 5. Gate update prompts on "no inspection in progress". ## Verification - Test a production build served locally in a private window; switch the browser to offline and reload. - Visit the worker's debug page at `/ngsw/state` to see which version is installed and whether it is in a degraded state. - Walk the full route: open online, go offline, start the app, open an inspection type never visited before, submit, come back online, confirm the outbox drains. ## Summary The Angular worker gives offline **start** and offline **reads**: prefetch code, add `freshness` and `performance` data groups, ensure installation while online. Offline **writes** are the application's job.
- Why might an inspector who opened the app in the depot still find it unavailable offline?The worker may not have registered or finished caching a complete version. With the default `registerWhenStable:30000`, registration waits for the app to stabilize for up to 30 seconds, and the prefetch download follows. Registering immediately and checking the installed version before trips reduces the risk.
- Why must the app merge its local outbox with the cached inspection list?Offline, the freshness group returns the last cached list, which predates the inspector's work. Without merging pending local submissions over it, completed inspections would appear open, and the inspector might redo them or think results were lost.
saying these in an interview costs you the question
- The service worker queues offline POSTs and replays them automatically
- The generated ngsw-config.json already caches API data
- A freshness group serves cached data of any age when offline
- Installing the app once years ago is enough for today's release offline
- Lazy route chunks must be excluded from prefetch to save space