Qwik useVisibleTask alert gating after viewport intersection

Question

Qwik useVisibleTask alert gating after viewport intersection
The goal is to surface browser alerts only when a Qwik component enters the viewport, using useVisibleTask so notifications do not fire during SSR or initial hydration. A reactive store holds pending alert entries, and the task should enqueue an alert only when a new entry exists and visibility is confirmed.
The unresolved constraint is whether useVisibleTask in Qwik 1.x requires an experimental opt-in, and exactly when the callback executes relative to client hydration and first visible paint. It is also unclear whether visibility state resets after client-side navigation and whether pending store entries survive that boundary without re-fetching.
Does useVisibleTask require the qwik-experimental flag in Qwik 1.x? Does the callback run after hydration completes but before the component is scrolled into view? Do pending alert entries in a reactive store persist across navigation when the component remounts?

Tasadduq Burney · Answer

Direct answer
No. In Qwik 1.x stable releases useVisibleTask$ is a core browser-only hook from @builder.io/qwik. It does not require a qwik-experimental opt-in. The callback is not tied to hydration completion or first paint; it runs only when the host element actually intersects the viewport via IntersectionObserver. Pending alert entries survive client navigation only if the store lives outside the component remount scope. A component-local useStore is recreated on remount.
Confirmed facts

useVisibleTask$ is browser-only. It does not execute during SSR and is not invoked on initial render.
The callback is scheduled via IntersectionObserver after hydration. Visibility is determined by intersection, not by hydration timing.
The callback runs only when the host element becomes visible in the viewport. It does not run after hydration completes but before scrolling.
Visibility state resets when the component unmounts. After client-side navigation the element is recreated and a new observation is established.

Likely behavior, version-sensitive

In Qwik 1.x stable the hook is part of core. The experimental flag was associated with earlier previews. Verify the installed major version and import path.
Pending alert entries in a reactive store persist across navigation only if the store is navigation-scoped, e.g., a module singleton or a context provider. A component-local useStore is recreated on remount and loses pending entries.

Steps for this case

Keep pending alerts in a navigation-scoped store, not component-local. A module singleton or a context provider survives route changes.
Use useVisibleTask$ to gate the alert. Check for a new entry inside the visible callback and clear it after enqueueing to avoid repeat fires on re-intersection.
Do not assume first paint triggers the task. Test with actual scroll into view and confirm IntersectionObserver availability in target browsers.

One diagnostic detail that changes the recommendation: is the pending alert store a component-local useStore or a module/context-scoped store? If it is component-local, pending entries will be lost on remount and you need to lift the store.

Qwik useVisibleTask alert gating after viewport intersection