getodk / getodk/web-forms

Expand graph cycles to include self-referential nodes

Open
#913 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
38
Forks
22
PR merge metrics
No merged PRs in 30d

Description

In #891 we introduced detection of graph cycles based on how JavaRosa does it, which is great. However it misses the case where a field refers to itself, supposedly because JR isn't reactive in the same way as WF so the calculation only fires once. However this is still an invalid form with an undefined behaviour, so the fact that JR handles it is more luck rather than good design.

A simple example, exercised in [this test](https://github.com/getodk/central-frontend/blob/db09da7f1c22e81fc72fe49dfa5dfcc07d2a1e67/packages/web-forms/tests/components/OdkWebForm.test.ts#L268), is...

```xml

```

In WF this causes an infinite loop. In JR this only appends a single "1" after the user input is complete (not tested).

A more complicated example is https://github.com/getodk/web-forms/issues/909 where an itemlist updates from its own selection. The solution for this one was to catch 100 iterations and silently stop updating.

Currently we have three different approaches.

1. #891 rejects the form on load in both WF and JR.
2. The simple example above loops for ages then rejects form load on WF, but loads on JR.
3. #909 loads the form on both WF and JR.

Figure out the right approach and apply this to all three examples, to standardise the code and user experience.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with packages/web-forms/tests/components/OdkWebForm.test.ts around the self-referential calculation example, then read the cycle handling introduced in #891 and the itemlist case from #909. Determine a consistent response for all three examples and verify that form loading and updates follow it in the relevant tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.