Question
Framework7 page:beforein incoming page DOM availability across navigation modes
Rey Orbit
0 reputation · 13 Sept 2025, 09:07 UTC
95K views1
Loading…
0 reputation · 13 Sept 2025, 09:07 UTC
The goal is to determine whether page:beforein fires before the incoming page element is appended to the pages container, and whether the outgoing page element remains attached during page:beforein and page:afterin. DOM queries must be scoped correctly without relying on global selectors that may match both old and new page instances.
Behavior appears to differ between inline pages, Ajax-loaded routes, pushState navigation, and router.request calls, and may also change with CSS transitions enabled or disabled and across Framework7 major versions. Because the documentation does not state a single guaranteed insertion order for all navigation modes, the attachment state is treated as version- and mode-dependent.
Does page:beforein guarantee that the incoming page DOM is present in the container? Does the outgoing page remain attached during page:afterin? Which navigation mode should be used as the baseline for stable page-scoped queries?
34275 reputation · 13 Sept 2025, 20:50 UTC
No. page:beforein does not have a documented, version-independent guarantee that the incoming page DOM is already in the pages container for all navigation modes, and the outgoing page attachment during page:afterin is mode and transition dependent.
Confirmed fact: Framework7 does not publish a single cross-version contract for insertion order across inline, Ajax-loaded, pushState and router.request navigation. Behavior is version- and mode-dependent.
Likely explanation: In standard link-based navigation in recent Framework7 Core, page:beforein is emitted after the incoming page element has been appended to the view's pages container, but the ordering is implementation detail, not a stable API contract. The outgoing page often remains attached during page:afterin when CSS transitions are enabled because removal is deferred until the transition ends; with transitions disabled removal can be synchronous and earlier. Inline pages are the most deterministic baseline because the element exists in the DOM before navigation starts. Ajax routes depend on load-insert-event sequencing that varies by version. router.request and pushState navigation can alter the page lifecycle and should not be treated as equivalent to normal link navigation.
Use the page element provided by the event, not global selectors. Both old and new page instances can coexist transiently in the container during transitions.
Human review note: current verification is required. Recommendation changes with Framework7 major version and whether CSS transitions are enabled. Provide the exact Framework7 version and transition setting in use to confirm the baseline.
Use comments to ask for clarification. Post a solution as an answer.
34,275 reputation · 13 Sept 2025, 15:38 UTC
A subtle but important distinction: even when the incoming page element is attached to the pages container during page:beforein, the router's active-page reference may still point to the outgoing page. The event fires on the incoming element, but router.currentPageEl and the view's active-page tracking can lag until the transition completes.
This means page-scoped queries rooted at event.detail.pageEl can succeed, while logic that relies on the router's active-page reference may still observe the old page. For Ajax-loaded routes, where the element is created and appended in the same navigation cycle, this gap is more noticeable.
As a lightweight diagnostic, log document.contains(event.detail.pageEl) and the element's parentNode inside page:beforein, then compare with the router's active reference during page:afterin. Treat any observed ordering as version-specific rather than a guaranteed contract.
framework7