Imagine you have a repeating form. In the second entry, we type something that causes the backend process to generate an error for that path. This is happening but then we quickly remove the first entry. The path returned is now 1 too big and the message is associated with the wrong accessor.
How to solve this? Various potential solutions:
-
when we modify a repeating form we somehow ignore any paths coming in for it. Drawback: no validation errors show up while we should get them, until you interact with the form again causing a change event. Also tricky book keeping.
-
when we do an insert or delete of repeating form, we always wait until there's a "gap" in processing. Drawback: potential slowdown for user. Insert and delete become asynchronous. Have to use that API and nothing else (like node directly) to modify the form.
-
use something else than the path to uniquely identify a field. Drawback: lots of code built around the path concept.
-
use a value in addition to the path. This value is changed whenever we modify the form in a repeating form style way - like a counter or a checksum. The server sends back this value by echoing it. If we have mismatching counters, we resubmit the process request with the new form state and ignore the old information. Drawback: if the user interacts with the form a lot it will take a lot of requests?
I think the last approach offers the most possibility and is fairly simple. We could have a counter that responds to any form modification (so we only accept updates if the form hasn't changed in the mean time - this is another approach perhaps less complicated than the change tracker we have now). This should still work with debouncing too I think.
Imagine you have a repeating form. In the second entry, we type something that causes the backend process to generate an error for that path. This is happening but then we quickly remove the first entry. The path returned is now 1 too big and the message is associated with the wrong accessor.
How to solve this? Various potential solutions:
when we modify a repeating form we somehow ignore any paths coming in for it. Drawback: no validation errors show up while we should get them, until you interact with the form again causing a change event. Also tricky book keeping.
when we do an insert or delete of repeating form, we always wait until there's a "gap" in processing. Drawback: potential slowdown for user. Insert and delete become asynchronous. Have to use that API and nothing else (like node directly) to modify the form.
use something else than the path to uniquely identify a field. Drawback: lots of code built around the path concept.
use a value in addition to the path. This value is changed whenever we modify the form in a repeating form style way - like a counter or a checksum. The server sends back this value by echoing it. If we have mismatching counters, we resubmit the process request with the new form state and ignore the old information. Drawback: if the user interacts with the form a lot it will take a lot of requests?
I think the last approach offers the most possibility and is fairly simple. We could have a counter that responds to any form modification (so we only accept updates if the form hasn't changed in the mean time - this is another approach perhaps less complicated than the change tracker we have now). This should still work with debouncing too I think.