Summary
In useScrollTrigger (packages/hamo/src/use-scroll-trigger/index.ts), update() is a stable useEffectEvent, and the effects that invoke it depend only on [lenis, update, ...deps]. The computed startValue / endValue depend on the element rect, window height, start/end, and offset — but a change to any of those does not re-run update(). So after a resize (or other geometry change) without a subsequent scroll, the reported progress can be stale until the next scroll / transform tick.
Surfaced by an independent cross-model (Codex) review during the v1 hardening (#12).
Important context
This is pre-existing behavior, not introduced by the v1 maintainability pass — the update effect dependency arrays are byte-identical to the original port (#11 / commit 428de5e). It is verified not a regression, so it does not affect #12's behaviour-preserving claim. Filing it so the limitation is tracked rather than lost.
Repro (conceptual)
- Mount a
useScrollTrigger with onProgress.
- Resize the window (or change the element's size/position) without scrolling.
onProgress does not re-fire with the recomputed start/end until the next scroll or transform update.
Options to evaluate
- Re-run
update() when startValue / endValue (or their inputs) change — e.g. add the derived values to the relevant effect's dependency array.
- Or explicitly recompute on resize via the existing
useWindowSize / useRect signals.
- Confirm whether this is intentional (scroll-driven recompute only) — if so, document it.
Notes
Summary
In
useScrollTrigger(packages/hamo/src/use-scroll-trigger/index.ts),update()is a stableuseEffectEvent, and the effects that invoke it depend only on[lenis, update, ...deps]. The computedstartValue/endValuedepend on the element rect, window height,start/end, andoffset— but a change to any of those does not re-runupdate(). So after a resize (or other geometry change) without a subsequent scroll, the reported progress can be stale until the next scroll / transform tick.Surfaced by an independent cross-model (Codex) review during the v1 hardening (#12).
Important context
This is pre-existing behavior, not introduced by the v1 maintainability pass — the
updateeffect dependency arrays are byte-identical to the original port (#11 / commit428de5e). It is verified not a regression, so it does not affect #12's behaviour-preserving claim. Filing it so the limitation is tracked rather than lost.Repro (conceptual)
useScrollTriggerwithonProgress.onProgressdoes not re-fire with the recomputed start/end until the next scroll or transform update.Options to evaluate
update()whenstartValue/endValue(or their inputs) change — e.g. add the derived values to the relevant effect's dependency array.useWindowSize/useRectsignals.Notes