fix(views): remove the dead form.data provider from all twelve views - #555
Merged
Conversation
`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>
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
pnpm verifyonmainreported 12liveness-dead-propertywarnings — one per view file — for the form view's data provider: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
viewsexports, so it reports live routes as dead (documented in #544). So the behaviour was checked directly on 16.1.0, with everyform.dataalready deleted:/…/crm_lead/record/_x1aq0Snac7Qc6gp?form=…first_name: "Mira",last_name: "Costa",company: "Atlas Construction",status: "contacted",lead_source: "cold_call"The form binds exactly as the liveness rule describes.
Guards
Two assertions in
test/metadata-references.test.ts:form.dataagain. Runs red on the pre-fix tree —crm_lead: form.data = {"provider":"object","object":"crm_lead"}— and green after.list.data.object.objectOf()used to fall back toform.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 onobjectOf()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 carrydatablocks — 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:liveness-dead-propertygone; what remains is the two pre-existingcampaign_enrollmentflow-variable notes (documented as safe to ignore) plus their summary lineType of Change
Checklist
pnpm verifypasses