feat(ads): carry the banner scroll position across navigation
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Successful in 9s
CI / integration (pull_request) Successful in 13s
CI / ui (pull_request) Successful in 49s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 57s

Per the owner's idea: instead of moving the banner out of the per-screen header
(which would change its position), remember the banner's "life stage" and resume
it on the next screen. The engine already keeps the message + rotation timing;
this adds the scroll offset:

- bannerEngine tracks the in-flight scroll (target, duration, start). On attach,
  if a scroll is still running, it computes the current offset and calls the new
  host's resumeScroll(fromTx, toPx, remaining) — the view jumps to the carried
  offset and continues to the end over the remaining time, instead of restarting
  at the left.
- A finished scroll is left at its end; the rotator's own loop then takes over.

Verified: spot-checked in the browser (a long message at offset -785 resumes at
-788 on the next screen, not 0) and unit-tested (attach mid-scroll calls
resumeScroll with a partial offset and the remaining duration).
This commit is contained in:
Ilia Denisov
2026-06-16 06:26:12 +02:00
parent dc582e9f73
commit 9f83962bf7
4 changed files with 62 additions and 3 deletions
+10
View File
@@ -70,6 +70,16 @@
txDur = durationMs;
tx = -toPx;
},
resumeScroll(fromTx, toPx, durationMs) {
// Jump to the carried-over offset instantly, then continue to the end over the remaining
// time — so a long message keeps its scroll position across a navigation.
txDur = 0;
tx = fromTx;
requestAnimationFrame(() => {
txDur = durationMs;
tx = -toPx;
});
},
};
// Attach to the persistent engine on mount, detach on unmount (without stopping it). Declared