When fastDomIf is enabled (legacy-undefined-noBatch branch), path notifications will batch in syncInfo until the dom-if becomes truthy again, at which point all batched path notifications will be included in changedProps. Polymer 2/3 has a rule that paths must not be batched, because the property effect de-duping mechanism will only present the first matching path to an observer, which is unexpected and can cause program errors.
Although there is a fundamental flaw in Polymer 2/3's "falsey dom-if squelchinng" related to path notifications (#4818), fastDomIf mistakenly batches them rather than dropping them like the non-fastDomIf case, and keeps them batched across re-stamped instances, which even when using the workarounds for #4818 (restamp or mutable-data) can still cause errors. The goal for this issue is to match the non-fastDomIf behavior & limitations.
Description
When
fastDomIfis enabled (legacy-undefined-noBatchbranch), path notifications will batch insyncInfountil thedom-ifbecomes truthy again, at which point all batched path notifications will be included inchangedProps. Polymer 2/3 has a rule that paths must not be batched, because the property effect de-duping mechanism will only present the first matching path to an observer, which is unexpected and can cause program errors.Although there is a fundamental flaw in Polymer 2/3's "falsey dom-if squelchinng" related to path notifications (#4818),
fastDomIfmistakenly batches them rather than dropping them like the non-fastDomIf case, and keeps them batched across re-stamped instances, which even when using the workarounds for #4818 (restampormutable-data) can still cause errors. The goal for this issue is to match the non-fastDomIf behavior & limitations.Versions
legacy-undefined-noBatchbranch)