Vendors list — first 100, load more, Preferred cookie

p11-page-vendors part 3 (branch p11-vendors-chunk), captured on a synthetic 120-vendor company on stage

24 Sept 2026 · branch p11-vendors-chunk · captured against propflow-stage · at 7db8db919b

Data note. Every name and balance below comes from propflow-stage, which is anonymized by construction (ADR-0097/0110 — phones in the impossible +1000 NPA, emails @example.test). The identical capture against prod would carry real tenants' names and balances and is not safe to attach anywhere, which is why the generator refuses to run against one.

1 · Priming: pick the All view once

A fresh browser remembers no view, so the page opens on Preferred (the default). Picking All here stores the choice (localStorage) and mirrors it into the propflow-vendors-view cookie; every later section in this browser opens on All.

Server log for this section: the page render, then GET /api/vendors?limit=1000&cursor=… — the follow-up read the Preferred view needs when no cookie sized the first read. This is the loading flash the cookie removes (compare section 5).

Asserted in the captured DOM — Who Clara calls first is set per property on the Preferred tab.

Priming: pick the All view once

2 · (a) All view: the first paint is 100 vendors

The server seeds one window of 100 vendors (vendorId order) with their contacts. More exist, so the count reads as a lower bound.

Asserted in the captured DOM — 100+ vendors · Fixture Plumbing 001 · Fixture Contact 001

(a) All view: the first paint is 100 vendors

3 · (a) Load more: reaching the last loaded page appends the rest

The table holds 50 rows a page, so 100 loaded vendors are two pages. Paging to page 2 (the last loaded page) asks for the next chunk: the remaining 20 vendors are appended, the count becomes exact and a third page appears, shown here with vendors 101–120.

Asserted in the captured DOM — Fixture Handyman 120 · Fixture Contact 120 · Showing 101–120 of 120

(a) Load more: reaching the last loaded page appends the rest

4 · (c) Search finds a vendor past the first 100

Searching for 117 on a fresh landing (only 100 loaded) walks the rest of the company and finds vendor 117.

Asserted in the captured DOM — Fixture Plumbing 117 · 1 of 120

(c) Search finds a vendor past the first 100

5 · (b) Preferred cookie: the landing

A browser whose cookie says Preferred. The server reads the whole company in its one render. The smoke user is platform staff and this company has no properties, so the Preferred view asks for a property: that prompt is expected, and it is not a loading state.

Server log for this section: the page render and no /api/vendors request at all — the one server read already held the whole company, so the island made no follow-up.

Asserted in the captured DOM — Pick a property up top to see its go-to vendors.

(b) Preferred cookie: the landing

6 · (b) Preferred cookie: the whole company was already loaded

Switching to All in the same browser shows an exact 120 with no lower bound.

Asserted in the captured DOM — 120 vendors · Fixture Plumbing 001

(b) Preferred cookie: the whole company was already loaded

Notes and what was not captured

Data. Every row is a synthetic fixture: one sandbox company (org_fixture_vdiff_20260924) with 120 vendors written through the repo's data-layer writers on propflow-stage, deleted after capture and verified gone by read-back. Phones use the impossible 000 area code and emails @example.test.

Critique round 1. The first load-more capture used a full-page shot, and the fixed sidebar and top bar were drawn half-way down the image, covering the table toolbar. That is a full-page capture artifact, not a product defect; the section was re-shot at the fold, scrolled to vendor 120, with the pager text asserted instead.

Critique round 2 (against brand-and-design.md). The list follows the list-page skeleton (PageHeader, one primary action, DataTable with search, Trade filter, page-size ladder, count label). The count reads 100+ vendors while more exist and becomes exact after the append; a search reads 1 of 120 once the walk reaches the end. Two things on screen are not from this change: the floating Clara button covers the last row's Delete link and the pager's Next at the right edge, and the Next.js dev badge sits over the user chip (dev server only). The Preferred prompt for staff with no property is one muted sentence rather than a title plus next action (rule 15); it is existing copy, not part of this diff.

Not captured: (d) a failed next chunk. Producing it needs a failing request, and this tool deliberately refuses to rewrite responses (page.route). Covered by VendorsClient.load-more.test.tsx only.

PropFlow Docs