Closed arturbasinki closed 2 months ago
Thank you for reporting this! I can reproduce this and will work on fixing it.
A summary of the situation here:
ShouldDisplayer
condition that was not previously satisfied in a Form
i, f
from the range loopi
to re-capture f
in inner closures to avoid f
becoming stalei
is actually the one that becomes stale, since the field index is different once a conditional changesf
should never become stale since the name is based on both the field path and the field type name, which should only both be the same if it is actually the same fieldf
will indeed be stale, since it has the same name and type, but it is a different actual field, and thus the value is never updated)f
instead of i
in the value widget Updater
, we would have a bunch of issues like that, so that is why we are using i
there)i
and f
at different points, but neither is actually robust with our current structure.f
extensively in the label closures, which is predicated on false assumptions and means that there are ways to break that logic (for example, if you set the struct of a Form to a struct that is otherwise the same but has different default
struct tags or different documentation, it will not update accordingly; that is an exceedingly rare possibility and not worth fixing now; see #1098)i
to the name in the plan, ensuring that it is never stale, and then always use i
as the ground truth and never f
. That approach is somewhat similar to what we do elsewhere and probably the best way forward at this point.@rcoreilly any thoughts? Good for me to move forward with the plan stated in the last bullet point?
last option sounds fine to me..
Describe the bug
demo app crashes on linux
How to reproduce
App crashes during testing Collections
Example code
No response
Relevant output
Platform
Linux