S-26/#162 · Werkbak refreshes itself when a registration is ready for beoordeling (#164)
## What & why The behandel werkbak now **refreshes itself** while it is open, so a registration that reaches beoordeling after the behandelaar opened the page shows up on its own — no reload. `interval(WERKBAK_REFRESH_MS)` (5 s) re-reads the existing BFF endpoint, scoped to the page with `takeUntilDestroyed()`. A *background* read leaves the rows and states on screen alone until it has an answer, so a tick never flashes the loading state over rows being read and one failed poll never swaps the list for the error alert; a read that comes back also clears an earlier failure, so the view recovers on its own rather than needing the very reload this slice removes. No new endpoint, dependency or server-side state, and no service boundary moves — rxjs and `GET /behandel/werkbak` are both already here. **ADR-0032** records why polling rather than a pushed stream: nothing notifies the BFF either, so SSE/WebSockets would poll the domain *inside* the BFF for the same freshness, plus connection lifecycle, nginx buffering and a stateful BFF. Proposal: #163. Closes #162 ## Definition of Done - [x] Linked Gitea issue (above). - [x] Failing test committed before the implementation. - [x] Implementation makes the test pass; refactor commit if structure improved. - [x] Conventional Commits referencing the issue (`refs #162`). - [ ] CI green — all Gitea Actions jobs. - [x] `docker compose up` from a fresh clone reaches green health checks within 3 minutes (unchanged; only the behandel bundle differs). - [x] Docs updated if behaviour, contracts, or operations changed. - [x] ADR added in `docs/architecture/` (ADR-0032). - [x] Demo note in `docs/demo-script.md` (user-visible). ## Notes for reviewers **The e2e is the real acceptance test, and it took two goes to make it one.** Simply dropping the `staff.reload()` from the happy path proved nothing: the werkbak was visited *after* the documents were supplied, so the row was already there at page load. The spec now logs the behandelaar in **first**, asserts the row is not there yet, and only then has the citizen supply the documents that route it to Beoordelen — so the row can only reach that already-open, never-reloaded page via the refresh. Verified both ways against a live stack: with the interval stubbed out it fails at `Goedkeuren <ref> … element(s) not found` after 30 s; with it, the behandel nginx logs the poll that delivers the row. The page is foregrounded before the assertion because Chromium throttles timers in a hidden tab. **Ceiling (named in the ADR):** a fixed 5 s interval, per open page, that keeps polling in a background tab; each tick costs one Flowable task query plus a store read per open task. Upgrade path: publish task events from the domain, then swap the `interval` for a stream — the endpoint contract and the rendering stay put. Gate on `document.visibilityState` first if request volume is the concern. **Two housekeeping notes, neither blocking:** - #162 is on **no milestone** (DoD item 1). It is portal UX, so it fits neither *Data Governance* nor *Production Posture* cleanly — your call where it lands. - The issue titles itself **S-26**, which already belongs to the self-service resume slice (#111, `BACKLOG.md`). Everything here references **#162**; worth renumbering the title if the S-ids are meant to stay unique. `BACKLOG.md` is untouched for the same reason (it mirrors the active milestone, and this slice is on none).Reviewed-on: #164
This commit was merged in pull request #164.
This commit is contained in:
@@ -1,7 +1,15 @@
|
||||
import { Component, inject, signal } from '@angular/core';
|
||||
import { takeUntilDestroyed } from '@angular/core/rxjs-interop';
|
||||
import { interval } from 'rxjs';
|
||||
import { BffApiV1Service, type WerkbakItem } from 'api-client';
|
||||
import { UtrechtComponentsModule } from 'ui';
|
||||
|
||||
/**
|
||||
* How often an open werkbak re-reads itself (S-26/#162, ADR-0032). Exported so the spec advances the
|
||||
* clock by exactly one interval instead of hard-coding the number.
|
||||
*/
|
||||
export const WERKBAK_REFRESH_MS = 5_000;
|
||||
|
||||
/** The two decisions a behandelaar can make; the BFF validates these exact values (ADR-0013). */
|
||||
type Besluit = 'goedkeuren' | 'afwijzen';
|
||||
|
||||
@@ -10,6 +18,11 @@ type Besluit = 'goedkeuren' | 'afwijzen';
|
||||
* Flowable `Beoordelen` tasks, read through the domain) and decides each — goedkeuren or afwijzen. A
|
||||
* decision posts to the BFF, which applies the domain transition and completes the workflow task
|
||||
* (ADR-0013; S-12). After a decision the werkbak refreshes so the handled item drops off the list.
|
||||
*
|
||||
* The page also re-reads itself every {@link WERKBAK_REFRESH_MS} while it is open, so a registration
|
||||
* that reaches beoordeling after the behandelaar opened the werkbak shows up on its own — no reload
|
||||
* (S-26/#162). Polling rather than a pushed stream: nothing notifies the BFF either, so a stream
|
||||
* would poll the domain in the BFF instead and add connection state for the same freshness (ADR-0032).
|
||||
*/
|
||||
@Component({
|
||||
selector: 'app-werkbak-page',
|
||||
@@ -27,19 +40,37 @@ export class WerkbakPage {
|
||||
|
||||
constructor() {
|
||||
this.load();
|
||||
// ponytail: a fixed interval, polled while the page lives — it keeps refreshing in a background
|
||||
// tab. Gate on `document.visibilityState` if the request volume ever matters.
|
||||
interval(WERKBAK_REFRESH_MS)
|
||||
.pipe(takeUntilDestroyed())
|
||||
.subscribe(() => this.load({ background: true }));
|
||||
}
|
||||
|
||||
load(): void {
|
||||
this.loading.set(true);
|
||||
this.failed.set(false);
|
||||
/**
|
||||
* Read the werkbak. A `background` read is the interval refresh: it leaves the rows and the states
|
||||
* the behandelaar is looking at alone until it has an answer — no loading flash on every tick, and
|
||||
* a blip does not swap the list for the failure alert (the next tick recovers). Only a foreground
|
||||
* read — on open, or after a decision — speaks for whether the werkbak is readable at all.
|
||||
*/
|
||||
load(options: { background?: boolean } = {}): void {
|
||||
const background = options.background ?? false;
|
||||
if (!background) {
|
||||
this.loading.set(true);
|
||||
this.failed.set(false);
|
||||
}
|
||||
this.bff.getBehandelWerkbak().subscribe({
|
||||
next: (rows: WerkbakItem[]) => {
|
||||
this.items.set(rows);
|
||||
this.loading.set(false);
|
||||
this.loaded.set(true);
|
||||
// A read that came back is the answer, so a refresh also clears an earlier failure — the
|
||||
// werkbak recovers on its own instead of showing the error until someone reloads.
|
||||
this.failed.set(false);
|
||||
},
|
||||
// Surface the failure (e.g. 403 for a non-behandelaar) instead of swallowing it.
|
||||
error: () => {
|
||||
if (background) return;
|
||||
this.items.set([]);
|
||||
this.loading.set(false);
|
||||
this.loaded.set(true);
|
||||
|
||||
Reference in New Issue
Block a user