Skip to content

fix(views): remove the dead form.data provider from all twelve views - #555

Merged
yinlianghui merged 1 commit into
mainfrom
fix/dead-form-data-provider
Jul 30, 2026
Merged

fix(views): remove the dead form.data provider from all twelve views#555
yinlianghui merged 1 commit into
mainfrom
fix/dead-form-data-provider

Conversation

@yinlianghui

Copy link
Copy Markdown
Collaborator

Description

pnpm verify on main reported 12 liveness-dead-property warnings — one per view file — for the form view's data provider:

form: {
  type: 'tabbed',
  data: { provider: 'object', object: 'crm_contact' },   // ← never read
  sections: [  ],
}

A form binds to its object and record through the route context, so the block only ever looked like it was wiring the form to an object. List views do honour a data provider; form views do not. This removes all twelve.

Measured before removing

The validator's word alone was not enough here: the same validator produces false positives elsewhere — it cannot see view names inside the twelve grouped views exports, so it reports live routes as dead (documented in #544). So the behaviour was checked directly on 16.1.0, with every form.data already deleted:

Check Result
Lead record edit form opens /…/crm_lead/record/_x1aq0Snac7Qc6gp?form=…
Fields bound to the record ✅ 8 inputs, 7 populated
Sample values first_name: "Mira", last_name: "Costa", company: "Atlas Construction", status: "contacted", lead_source: "cold_call"
Console / form errors ✅ none

The form binds exactly as the liveness rule describes.

Guards

Two assertions in test/metadata-references.test.ts:

  1. No view may declare form.data again. Runs red on the pre-fix tree — crm_lead: form.data = {"provider":"object","object":"crm_lead"} — and green after.
  2. Every view still resolves its object from list.data.object. objectOf() used to fall back to form.data.object. Removing those blocks silently narrows it to the list provider; without this check, a view that ever lost both would make every rule keyed on objectOf() skip it instead of failing — the "green test that checks nothing" this file already has scar tissue about.

Deliberately left alone

Named forms under formViews (quick_create, lead_conversion_wizard, …) still carry data blocks — 8 of them. The liveness rule does not flag those, and they are unmeasured: a create form has no record in the route context, so the same reasoning may not hold. Removing them on the strength of a neighbouring shape's verdict is exactly the mistake #554 had to walk back. Measure first if anyone wants them gone; the guard's comment says so.

Verification

pnpm verify (validate → typecheck → build → test) on a clean checkout:

  • exit code 0, 0 errors
  • warnings 15 → 3: all 12 liveness-dead-property gone; what remains is the two pre-existing campaign_enrollment flow-variable notes (documented as safe to ignore) plus their summary line
  • 140/140 tests passing (11 files; was 138 before the two new guards)

Type of Change

  • Bug fix (non-breaking change which fixes an issue)

Checklist

  • pnpm verify passes
  • Guard fails before the fix, passes after
  • Behaviour verified in the browser, not inferred from the schema
  • Changeset added

`pnpm verify` on main reported 12 `liveness-dead-property` warnings — one per
view file — for a `data: { provider: 'object', object: 'crm_*' }` block on the
form view. A form binds to its object and record through the route context, so
the block only looked like it was wiring the form to an object.

Measured before removing, because the same validator produces false positives
elsewhere (it cannot see view names inside the twelve grouped `views` exports,
so it reports live routes as dead — see #544). With every `form.data` deleted,
opening a lead record's edit form on 16.1.0 still binds correctly: 8 inputs, 7
populated from the record (first_name "Mira", company "Atlas Construction",
status "contacted", lead_source "cold_call"), no console errors.

Two guards added:
- no view may declare `form.data` again (fails red on the pre-fix tree);
- every view still resolves its object from `list.data.object`. objectOf() used
  to fall back to `form.data.object`; without that check, a view that lost both
  would make every rule keyed on objectOf() silently skip it instead of failing.

Left alone deliberately: named forms under `formViews` (quick_create,
lead_conversion_wizard, …) still carry `data` blocks. The liveness rule does not
flag those and they are unmeasured — a create form has no record in the route
context, so the same reasoning may not hold. Documented in the guard's comment.

verify: exit 0, 0 errors, 15 warnings → 3 (two pre-existing campaign_enrollment
flow-variable notes plus their summary line). 140/140 tests.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@vercel

vercel Bot commented Jul 30, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
hotcrm Ignored Ignored Jul 30, 2026 3:14pm

Request Review

@yinlianghui yinlianghui added bug Something isn't working metadata labels Jul 30, 2026
@yinlianghui
yinlianghui merged commit 1db7b95 into main Jul 30, 2026
10 of 11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working metadata

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant