MistDemo web: zoneName/zoneOwner on query panel (#438)

[leogdion]

Summary

• Rebased onto v1.0.0-beta.5 after Model zone payload fields: ownerRecordName, zoneType, deleted (#444) #451 (zone payload fields) merged
• Adds zone name / zone owner inputs to the MistDemo web query panel (MistDemo web UI: add zoneName/zoneOwner inputs to query panel #438)

Test plan

• Confirm web query panel zone fields round-trip against private DB custom zones
• CI green on v1.0.0-beta.5

Made with Cursor

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: c40424a1-a132-4d17-b800-fa4a7bfb4530

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

Review

Reviewed the diff (index.html, js/app.js, WebServerTests+Index.swift) against CLAUDE.md conventions. Overall this is a small, well-scoped change that plugs the existing server-side zoneName/zoneOwner support (from #451) into the web query panel's UI for both backends.

Code quality / correctness

• Good client-side guard: zoneOwner is only read when zoneName is non-empty (app.js:503), matching the server's zoneOwner requires zoneName validation in WebRequests.Query.init(from:) (WebRequests.swift:90-96). The comment explaining why is appropriate per the repo's "only comment on non-obvious WHY" convention.
• undefined handling is correct: postJSON does JSON.stringify(body) (app.js:158), which drops undefined-valued keys, so leaving Zone/Zone owner blank correctly omits zoneName/zoneOwner from the MistKit-mode request body rather than sending empty strings or null. Verified this is not silently sending zoneName: "" to CloudKit.
• CloudKit JS branch is symmetric: query.zoneID = zoneOwner ? { zoneName, ownerRecordName: zoneOwner } : { zoneName } correctly maps to CloudKit JS's ownerRecordName key inside zoneID, distinct from the MistKit-mode flat zoneName/zoneOwner keys — nice touch calling that out in a comment since it's genuinely non-obvious naming asymmetry between the two backends.
• Consistent with existing patterns: new inputs are added to setQueryControlsDisabled's id list so they're disabled during an in-flight query, matching how record-type/query-limit and friends are already handled.

Minor observations (non-blocking)

• If a user fills in "Zone owner" but leaves "Zone" blank, the owner value is silently dropped with no UI feedback (no error, no visual cue). Given this is a demo app, that's a reasonable tradeoff, but a title/tooltip on the zone-owner input noting the dependency could avoid confusion if this ever trips someone up.
• The query-zone placeholder text ("zone name (default: _defaultZone)") is a nice touch for discoverability — confirms the omitted-key behavior at the UI level too.

Test coverage

• indexExposesQueryZoneInputs follows the existing string-containment test pattern used throughout WebServerTests+Index.swift (checking served static HTML/JS content rather than exercising the server route directly). This is consistent with sibling tests in the same file (e.g. indexExposesDatabasePicker), so it's stylistically appropriate, though as with the other tests here it only proves the JS text exists, not that the runtime request-building logic is correct. Given js/app.js isn't covered by any JS runtime test harness in this repo, this is the established coverage ceiling for this file, not a gap introduced by this PR.
• No new server-side (Swift) test was needed since WebRequests.Query's zoneName/zoneOwner decode + validation already had coverage from Model zone payload fields: ownerRecordName, zoneType, deleted (#444) #451 — this PR only wires the browser UI to fields that already round-trip.

Security

No concerns — inputs are plain text values forwarded as JSON string fields through the existing typed Decodable request parsing (WebRequests.Query), same as recordType/limit. No injection surface introduced.

Performance

N/A — no hot paths touched; this only affects a demo app's static resources and per-query request construction.

Nice, minimal PR that does exactly what the title says. No blocking issues found.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.85%. Comparing base (8896986) to head (9bd09fa).
⚠️ Report is 4 commits behind head on v1.0.0-beta.5.

Additional details and impacted files

@@                Coverage Diff                @@
##           v1.0.0-beta.5     #453      +/-   ##
=================================================
+ Coverage          81.83%   81.85%   +0.02%     
=================================================
  Files                197      197              
  Lines               4778     4784       +6     
=================================================
+ Hits                3910     3916       +6     
  Misses               868      868              

Flag	Coverage Δ
mistdemo-spm-macos	11.22% <0.00%> (-0.02%)	⬇️
mistdemo-swift-6.2-jammy	11.22% <0.00%> (-0.02%)	⬇️
mistdemo-swift-6.2-noble	11.22% <0.00%> (-0.02%)	⬇️
mistdemo-swift-6.3-jammy	11.22% <0.00%> (-0.02%)	⬇️
mistdemo-swift-6.3-noble	11.22% <0.00%> (-0.02%)	⬇️
mistdemo-swift-6.4-jammy	11.22% <0.00%> (-0.02%)	⬇️
mistdemo-swift-6.4-noble	11.22% <0.00%> (-0.02%)	⬇️
spm	80.41% <100.00%> (-0.02%)	⬇️
swift-6.1-jammy	80.66% <100.00%> (+0.19%)	⬆️
swift-6.1-noble	80.63% <100.00%> (-0.02%)	⬇️
swift-6.2-jammy	80.43% <100.00%> (-0.17%)	⬇️
swift-6.2-noble	80.53% <100.00%> (+0.12%)	⬆️
swift-6.3-jammy	80.68% <100.00%> (+0.04%)	⬆️
swift-6.3-noble	80.40% <100.00%> (-0.11%)	⬇️
swift-6.4-jammy	80.55% <100.00%> (-0.02%)	⬇️
swift-6.4-noble	80.72% <100.00%> (+0.21%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[claude]

Review

Nicely scoped, well-tested change for the stated goal (issue #438: zone name/owner inputs on the web query panel). The ZoneSelector decode/validation, the flat-wire-format-in/structured-model-out split in WebRequests.Query, and the CloudKit-JS ownerRecordName mapping in app.js are all clean and covered by tests (WebServerTests+QueryZone.swift, WebServerTests+Index.swift).

One scope concern worth a second look before merge:

Possible scope creep: zoneID added to write convenience methods, but unused by this PR

Sources/MistKit/CloudKitService/CloudKitService+RecordWriteConvenience.swift adds a new zoneID: ZoneID? = nil parameter to createRecord, updateRecord, and deleteRecord (core MistKit public API, not MistDemo). This is untouched by issue #438, which is explicitly scoped to the query panel only ("Follow-up from #426 ... web panel was intentionally deferred" for zone selection elsewhere).

Checking how it's wired into this PR's own MistDemo changes: it isn't.

• WebBackend.webCreate / webUpdate / webDelete (WebBackend.swift) still take no zone parameter.
• CloudKitService+WebBackend.swift's webCreate/webUpdate/webDelete call createRecord/updateRecord/deleteRecord without passing zoneID.
• app.js never sends zone info on create/update/delete requests (only queryNotes() was touched).

So after this PR, a user can filter the query panel by a custom/shared zone, but the Save/Delete buttons will still silently write to _defaultZone regardless of the zone shown in the query panel — the new API surface is exercised only by the new unit test (createForwardsZoneID), not by any real caller. Per CLAUDE.md: "Don't add features... beyond what the task requires." Suggest either:

1. Dropping the zoneID param from this PR and adding it (plus the full webCreate/Update/Delete → app.js wiring) in a follow-up scoped to write-zone support, or
2. If it's intentionally landing ahead of that follow-up, saying so in the PR description so reviewers know it's deliberately unwired for now.

Minor / nit

• WebRequests.ZoneSelector's doc comment says its zoneID property is "MistKit zone identity for queryRecords / modifyRecords" — currently it's only consumed by webQuery (i.e., queryRecords). Worth trimming the modifyRecords mention until the write path above is actually wired, so the comment doesn't imply behavior that doesn't exist yet.
• Test coverage for the new zoneID param on CloudKitService+RecordWriteConvenience only covers createRecord (createForwardsZoneID); updateRecord/deleteRecord don't have equivalent tests. Not blocking, but worth adding if the param is intentionally staying in this PR.

No correctness, security, or performance issues found in the reviewed diff — the zone-decoding validation (zoneOwner requires zoneName) and the request/response shape changes look correct and are exercised by tests.