A parent change must clear or revalidate the child

What it is

When the parent changes, a value already chosen in the child may stop being legal. The system must clear or revalidate at once: either bounce the child to empty, or confirm the old value still belongs to the new parent’s set and keep it. A city name that does not belong to the new province must not remain on the trigger. A silently kept stale value rides with the form and yields internal contradictions such as “province Jiangsu, city Hangzhou.”

Clear is the safe default; keep only after the old value is still legal. Keeping is a check, not sentiment about “the user already filled this.”

Why it happens

A child value is legal relative to its parent. After a new parent write, the old child’s frame of reference is gone. If the UI still shows the old child, people believe the combination holds — trigger text is trusted more than model constraints. The server may reject at submit, but rejection at the end makes them walk the whole chain to learn why. Worse, the server may not reject, and the dirty pair enters the store.

With more than two levels, a top change should fall like dominoes: every level recomputes against its immediate parent. Clearing only the second and leaving the third yields “category changed, model remains.” Validation has to walk the chain, not only the adjacent level.

Where it stops holding

When the old value has the same display name under the new parent but is not the same object (two provinces both have a “Chaoyang”), keeping by string binds the wrong id; check identifiers, and same-name still clears or asks for a re-pick. If the parent is rewritten elsewhere while the user is browsing the child panel (geolocation, co-editing), the clear must be visible, not a silent wipe in the model. Restoring an already-saved legal chain is not a “parent change” — that is resume, not rewrite. Frequent parent edits on a deep chain throw work away; a line such as “the following choices will reset” can name the cost, but the illegal values should still clear rather than be kept to honour labour.

Applying it

• On parent change, membership-check every descendant against the new parent set; clear anything not in the set at once.
• Let the clear show on the trigger; do not leave an old name beside a new parent.
• Reset the whole chain, and preview the loss when filled content is about to go.
• How to check: complete a chain, change the top, inspect downstream triggers. Any old name whose id does not belong to the new parent is a missed check.

Related

• Within the group: E3.13.1 Each next level’s options depend on the parent choice · E3.13.3 Too many levels make the cascade path too long · E3.13.4 Cascades are a poor fit when levels must be compared
• Adjacent: E3.11 Default-Value Strategy · E3.05 Select Menus
• Search terms: stale dependent value · cascade reset · revalidate child