Skip to content

Resolve conditions against the current row in repeated layouts - #1817

Open
craigmarker wants to merge 3 commits into
mainfrom
craig.marker/cdf-condition-repeated
Open

Resolve conditions against the current row in repeated layouts#1817
craigmarker wants to merge 3 commits into
mainfrom
craig.marker/cdf-condition-repeated

Conversation

@craigmarker

@craigmarker craigmarker commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

Summary

A condition's target field is an entity-relative path, so reusing the same condition config across every row of a repeated layout would otherwise only ever subscribe to the first row's field. Resolving the target against the current row requires splicing that row's index into the right spot in the path, so this adds that path-building step as its own tested helper and wires it directly into the condition renderer.

Test Plan

I ran the path-building helper's tests (index insertion, an exact-match root path, multiple existing indices in a nested repeated root, index 0) along with the condition renderer's tests covering: resolving against the indexed field for the current row, not matching against a different row's index in the same list, and reacting to changes at the indexed field rather than the unindexed entity path.

I also verified the fix interactively in the sandbox by adding a repeated-layout example whose condition depends on a field in the same row. With two rows rendered, checking the first row's "Show detail" box only revealed that row's detail field, and unchecking it removed it while the second row's own (independently checked) detail field and value stayed exactly as they were. The rendered field names confirmed each row's condition and target resolved against its own index (items[0].detail and items[1].detail), and submitting the form showed each row's values were tracked independently.

@github-actions

github-actions Bot commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

JavaScript Coverage Report

Total Coverage: 92.86%

Coverage Policy:

  • Baseline (existing code): ≥78.74% (current coverage)
  • New/changed code: ≥90% ✅ STRICTLY ENFORCED
Coverage Details
$(cat coverage/coverage-summary.json 2>/dev/null | node -p "const c=require('fs').readFileSync(0,'utf8'); JSON.stringify(JSON.parse(c).total, null, 2)" || echo "Coverage summary not available")

View detailed HTML report in artifacts

@craigmarker
craigmarker changed the base branch from craig.marker/cdf-condition-indexed-field-id to craig.marker/cdf-condition-is-only August 14, 2026 17:11
@craigmarker craigmarker changed the title Resolve condition targets against the current row in repeated layouts Resolve conditions against the current row in repeated layouts Aug 14, 2026
@craigmarker
craigmarker force-pushed the craig.marker/cdf-condition-is-only branch 2 times, most recently from 025131b to 7b45445 Compare August 18, 2026 19:16
Base automatically changed from craig.marker/cdf-condition-is-only to main August 18, 2026 19:27
@craigmarker
craigmarker force-pushed the craig.marker/cdf-condition-repeated branch from 48935df to e635fde Compare August 18, 2026 23:11
@codecov

codecov Bot commented Aug 18, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

Repeated layouts render one entity-relative config against every row
of an array, so a literal field id isn't enough on its own — it needs
the current row's index spliced into the right spot in the path. This
adds that path-building step as a standalone, independently tested
utility, ahead of wiring it into anything that consumes it.
layout.when is an entity-relative field path, so a single condition
config would otherwise only ever subscribe to the first row's field
when reused across a repeated layout. Wires buildIndexedFieldId into
FormCondition so the target resolves against the current row's index
whenever a RepeatedLayoutProvider is present, letting one condition
config apply uniformly to every row.
The sandbox had a condition example for a flat form but nothing
demonstrating a condition inside a repeated layout, so this fix had
no interactive way to verify row isolation outside its unit tests.
Adds a second row group where each item's detail field is gated on
that same item's own checkbox, exercising buildIndexedFieldId end to
end.
@craigmarker
craigmarker force-pushed the craig.marker/cdf-condition-repeated branch from e635fde to 06ce005 Compare August 18, 2026 23:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant