atomic-design-poc/docs/project/refactor-backlog-setup/refactor-backlog/implementation/rb-28.md

RB-28 — BLOB_PRESENTER token unlocks the three blob-to-browser success paths

Status: implemented · 2026-08-28 · Source finding: 02-testability.md TE-006 · 99-backlog.md RB-28

What was wrong

Three application-layer commands each ended in raw DOM/browser calls that jsdom cannot meaningfully execute: StamdataStore.download() (libs/beheer/src/application/stamdata.store.ts) did URL.createObjectURL → document.createElement('a') → a.click() → URL.revokeObjectURL; BriefStore.previewLetter() (apps/ssp/src/app/brief/application/brief.store.ts) and OrgTemplateStore.proefbrief() (apps/ssp/src/app/brief/application/org-template.store.ts) both did window.open(URL.createObjectURL(blob), '_blank'). Because the call was the last statement of each command, TE-006 recorded the whole success path as effectively unassertable, and download()'s two-clause guard (if (!s || !this.canDownload()) return;) as permanently dark on its true branch.

What changed

One new file, libs/shared/src/application/blob-presenter.ts, mirroring the SESSION_PORT token already in that folder — an interface, a production implementation, and an InjectionToken:

export interface BlobPresenter {
  open(blob: Blob): void;
  download(blob: Blob, filename: string): void;
}

const realBlobPresenter: BlobPresenter = {
  open(blob) {
    window.open(URL.createObjectURL(blob), '_blank');
  },
  download(blob, filename) {
    const url = URL.createObjectURL(blob);
    const a = document.createElement('a');
    a.href = url;
    a.download = filename;
    a.click();
    URL.revokeObjectURL(url);
  },
};

export const BLOB_PRESENTER = new InjectionToken<BlobPresenter>('BLOB_PRESENTER', {
  providedIn: 'root',
  factory: () => realBlobPresenter,
});

open() never revokes the object URL (the tab it opens outlives the call — BriefStore.previewLetter's original comment already said so and is preserved, moved onto the token's own doc comment); download() does revoke, once the click has fired. This asymmetry is preserved deliberately, not unified — the two call sites behaved differently before this ticket and still do.

Each of the three commands now injects BLOB_PRESENTER and calls it instead of the DOM directly:

File	Before (last statement)	After
stamdata.store.ts	createObjectURL → createElement('a') → click() → revokeObjectURL (6 lines)	this.blobPresenter.download(blob, \${s.table.id}.json`);`
brief.store.ts	window.open(URL.createObjectURL(r.value), '_blank')	this.blobPresenter.open(r.value);
org-template.store.ts	window.open(URL.createObjectURL(r.value), '_blank')	this.blobPresenter.open(r.value);

OrgTemplateStore.previewUrlFor (added by RB-24, a different seam — a document content URL for an <a href>, not a blob handoff) is untouched.

Tests added

libs/beheer/src/application/stamdata.store.spec.ts — a new StamdataStore.download (RB-28) describe block with a recording fake BlobPresenter:

1. Does not call the presenter while canDownload() is false because nothing is dirty yet — the guard's previously-dark true branch, first clause.
2. Does not call the presenter while previewing a date, even with a real edit present — the guard's true branch, second clause.
3. The success path, asserting toJson(...)'s exact output reaches the file: reads the recorded blob's text and compares it byte-for-byte against a direct call to toJson(store.table()!, store.rows()), and asserts the filename is professions.json.

apps/ssp/src/app/brief/application/brief.store.spec.ts — the existing BriefStore.previewLetter describe block's success test previously spied directly on window.open/URL.createObjectURL (both already jsdom-spyable, since the properties exist even though calling them for real throws "not implemented"). It now provides the recording fake via BLOB_PRESENTER and asserts opened holds exactly the resolved blob — the same outcome, reached through the new seam instead of monkey-patching two global browser objects.

apps/ssp/src/app/brief/application/org-template.store.spec.ts (new file — OrgTemplateStore had no spec at all before this ticket) — a OrgTemplateStore.proefbrief (RB-28) describe block: the success path (presenter receives the resolved blob, no error) and the failure path (presenter never reached, error surfaced). A Partial<UploadAdapter> stub with a no-op categoriesResource (status 'idle') satisfies the store's constructor effect without touching the logo-upload sub-state, which these tests do not exercise.

Verified red without the fix

Broke StamdataStore.download() with an Edit (not git checkout): changed the filename from `${s.table.id}.json` to `${s.table.id}.csv`. Ran the new success-path spec:

AssertionError: expected 'professions.csv' to be 'professions.json' // Object.is equality

Expected: "professions.json"
Received: "professions.csv"
 ❯ libs/beheer/src/application/stamdata.store.spec.ts:134:36

Re-applied the correct filename with a second Edit; the full stamdata.store.spec.ts file (6 tests) went green again.

Verification

• grep for remaining DOM blob calls in all three stores — grep -nE "window\.open|createObjectURL|revokeObjectURL|createElement\('a'\)|\.click\(\)" — zero matches. The only occurrences of those calls anywhere in apps/libs are inside blob-presenter.ts itself (checked with a second, unscoped grep — no fourth inlined handoff exists).
• npm run lint: clean.
• npm run dep:check: unaffected (no new import direction — libs/shared still does not depend on libs/beheer; both libs/beheer and apps/ssp/brief import the new token from libs/shared, never the reverse).
• npm test (all four projects): all pass — ssp 276, behandelportal 37, shared 138, beheer 26 (up from 23; +3 for the new download() describe block).
• Coverage, npm run test:coverage narrowed per project:
  • libs/beheer/src/application/stamdata.store.ts — before BRH 15 / BRF 37 (40.5% branch, confirmed against the current tree, matching TE-006's citation exactly); after BRH 25 / BRF 37 (67.6% branch). libs/beheer/src/application has exactly this one file, so the module figure moves the same way.
  • apps/ssp/src/app/brief/application/brief.store.ts — before BRH 39 / BRF 72 (54.2% branch). This is higher than TE-006's cited 32/64 (50%) because RB-22/RB-23 already added branches (the 404-tolerance path) since the finding was written — see "What TE-006 got wrong" below. After: BRH 39 / BRF 72, unchanged — swapping the global-spy assertions for the injected fake changes how the success branch is reached in the spec, not whether it is reached; it was already covered before this ticket (see below).
  • apps/ssp/src/app/brief/application/org-template.store.ts — no spec existed before this ticket, so there is no meaningful "before" branch figure for it specifically. After: BRH 17 / BRF 77, including both proefbrief() branches newly covered.
• npm run ci (foreground, timeout: 600000, no background/Monitor): result reported in the implementing agent's final answer.

What TE-006 got wrong

TE-006 states: "brief.store.spec.ts demonstrates this exactly: it tests previewLetter's failure case ... and cannot test the success case." This is not accurate for the code as it stood at the start of this ticket. The spec already had an 'opens the composed letter in a new tab on success' test that used vi.spyOn(URL, 'createObjectURL') and vi.spyOn(window, 'open') to assert the success path — jsdom defines both properties (as functions that throw "not implemented" if actually invoked), so vi.spyOn can already replace them, and the pre-existing test did. That test passed both before and after this ticket's change; this ticket did not newly unlock previewLetter's success path, it moved an already-passing assertion off two hand-spied global browser objects and onto the new injectable seam. git log --follow -p on the spec file shows this test dates to the WP-67 monorepo merge, not to any of RB-22/23/24.

The seam is still worth having: StamdataStore.download()'s success path (five DOM/API calls in a row: createObjectURL, createElement, .href, .download, .click(), revokeObjectURL) is a materially harder thing to spy on faithfully than a single window.open call, and was in fact still dark before this ticket (no download() test of any kind existed). OrgTemplateStore.proefbrief() also had no spec at all. TE-006's diagnosis (three commands share the same class of problem, one token fixes all three) is sound; only the specific "cannot test" claim about previewLetter overstates what was true for that one call site. Scope was not reduced because of this — all three call sites are migrated per the ticket's own instruction to ship them together rather than half-adopt the seam.

What this ticket did not touch

OrgTemplateStore.previewUrlFor (RB-24) — confirmed present and unchanged at org-template.store.ts:78. libs/shared/src/application/upload-shell.service.ts (RB-25) and upload-controller.ts (RB-26) — not read beyond what RB-24's own note already described, not edited. libs/shared/docs/behaviour-spec.mdx — regenerated by npm run gen:behaviour-spec (part of npm run ci) to reflect the new/renamed test names; never hand-edited.