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.
TODO:
getodk/web-forms@541cd12#diff-d7f5e2a9fa88fc71566d393928de170be5700174a890bc68e5195a4f8c6e1657R335
What has been done to verify that this works as intended?
These are test-only additions intended to capture the intended
indexed-repeat
behavior. It also updates the function's comment to better reflect the language that we use these days to talk about repeats.I wasn't there when the function was added by my understanding is that it was introduced so end users wouldn't have to write XPath predicates in the common case where they want to use a numeric index to access a specific repeat instance's value. XPath predicates are harder to reason about because the predicate expression is evaluated in the context of the path that's being filtered. It's particularly baffling when using parallel repeats because you end up having to write something like
position(.) = position(current()/..)
.The
indexed-repeat
function makes it so the index expression is evaluated using the bound node's context which is intuitive to users. The first parameter is the full reference to a field that needs to get indexed, and then there are some number of pairs of repeat references and indexes.A simple algorithm to think about the intended behavior (not exactly what JR does):
Why is this the best possible solution? Were any other approaches considered?
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
Do we need any specific form for testing your changes? If so, please attach one.
Does this change require updates to documentation? If so, please file an issue here and include the link below.