fix: signal-backed marker reactivity and stale signal re-push
Some checks failed
CI / Build and Test (push) Failing after 35s
CI / Build and Test (pull_request) Failing after 31s

Two issues discovered during testing:

1. data-effect expressions for signal-backed markers short-circuited
   before reading $signalID when the map hadn't loaded yet. Datastar
   never tracked those signals as dependencies, so the effect never
   re-ran. Fix: read signal values unconditionally before the guard.

2. prepareSignalsForPatch never reset changed=false on regular signals
   (only computed ones), causing every SyncSignals() call to re-push
   all signals — including stale server-side values for the draggable
   pin, overwriting the client-side drag position.
This commit is contained in:
Ryan Hamamura
2026-02-20 07:46:05 -10:00
parent b2474bf79d
commit 3c3ce57055
2 changed files with 7 additions and 3 deletions

View File

@@ -291,6 +291,7 @@ func (c *Context) prepareSignalsForPatch() map[string]any {
}
if sig.changed {
updatedSigs[sigID.(string)] = fmt.Sprintf("%v", sig.val)
sig.changed = false
}
case *computedSignal:
sig.recompute()

View File

@@ -233,12 +233,15 @@ func dragendHandlerJS(mapID, markerID string, mk Marker) string {
// markerEffectExpr generates a data-effect expression that moves a signal-backed marker
// when its signals change.
func markerEffectExpr(mapID, markerID string, mk Marker) string {
// Read signals before the guard so Datastar tracks them as dependencies
// even when the map/marker hasn't loaded yet on first evaluation.
return fmt.Sprintf(
`var m=window.__via_maps&&window.__via_maps[%s];`+
`var lng=$%s,lat=$%s;`+
`var m=window.__via_maps&&window.__via_maps[%s];`+
`if(m&&m._via_markers[%s]){`+
`m._via_markers[%s].setLngLat([$%s,$%s])}`,
jsonStr(mapID), jsonStr(markerID), jsonStr(markerID),
`m._via_markers[%s].setLngLat([lng,lat])}`,
mk.LngSignal.ID(), mk.LatSignal.ID(),
jsonStr(mapID), jsonStr(markerID), jsonStr(markerID),
)
}