Resolve conditions against the current row in repeated layouts - #1817
Open
craigmarker wants to merge 3 commits into
Open
Resolve conditions against the current row in repeated layouts#1817craigmarker wants to merge 3 commits into
craigmarker wants to merge 3 commits into
Conversation
Contributor
JavaScript Coverage ReportTotal Coverage: 92.86% Coverage Policy:
Coverage Details |
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
force-pushed
the
craig.marker/cdf-condition-is-only
branch
2 times, most recently
from
August 18, 2026 19:16
025131b to
7b45445
Compare
craigmarker
force-pushed
the
craig.marker/cdf-condition-repeated
branch
from
August 18, 2026 23:11
48935df to
e635fde
Compare
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
force-pushed
the
craig.marker/cdf-condition-repeated
branch
from
August 18, 2026 23:18
e635fde to
06ce005
Compare
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.
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].detailanditems[1].detail), and submitting the form showed each row's values were tracked independently.