Bug Report
Pen
Click the button once to toggle on, click again to toggle off; notice the lack of a reactive update to the second click.
It looks like setting a signal-object entry to null removes the key, but does not invalidate bindings that depend on key membership.
This means that things like like 'key' in $selection and Object.keys($selection) stay stale until an unrelated reactive change.
Possible cause is: at signals.ts:616 in the newValue == null branch, Datastar deletes deepObj[prop] but does not bump the key-tracking signal and does not dispatch(path, null):
|
if (newValue == null) { |
|
delete deepObj[prop] |
|
// if newValue is a computed set the computed directly instead of wrapping in signal |
|
} else if (hasOwn(newValue, computedSymbol)) { |
Possible fix is:
if (newValue == null) {
delete deepObj[prop]
dispatch(path, null)
keys(keys() + 1)
}
Datastar Version
RC8
Bug Report
Pen
Click the button once to toggle on, click again to toggle off; notice the lack of a reactive update to the second click.
It looks like setting a signal-object entry to
nullremoves the key, but does not invalidate bindings that depend on key membership.This means that things like like
'key' in $selectionandObject.keys($selection)stay stale until an unrelated reactive change.Possible cause is: at
signals.ts:616in thenewValue == nullbranch, Datastar deletesdeepObj[prop]but does not bump the key-tracking signal and does notdispatch(path, null):datastar/library/src/engine/signals.ts
Lines 616 to 619 in 173c1e1
Possible fix is:
Datastar Version
RC8