Slot Projection Timing Limits in newSpecPage

Slot Projection Timing Limits

\n

StencilJS’s newSpecPage renders a component in a simulated DOM and supports slot content projection. The API requires calling page.waitForChanges() after setting slot HTML to allow the framework to distribute child nodes. However, the documentation does not state whether a single waitForChanges is always sufficient when the projected content contains asynchronous components or side‑effects.

\n

Another area lacking clarity is the reset of component state between tests. The testing module does not automatically clear internal state, which may lead to cross‑test contamination unless a new spec page is instantiated each time or a manual reset strategy is employed.

\n

While developers can mock network requests using Vitest’s vi.mock or Jest‑style mocks, there is no built‑in registry in newSpecPage to persist these mocks across test files, raising questions about the most reliable approach to avoid production credentials in integration tests.

\n

Unresolved Questions

\n

\n
• Does a single call to page.waitForChanges() guarantee that all slot content, including asynchronous child components, is fully distributed, or are there documented scenarios that require multiple awaits?
\n
• What is the recommended pattern for resetting component state between tests when using newSpecPage to prevent cross‑test interference without creating a new spec page each time?
\n
• In a Vitest environment, what is the supported approach to globally mock network requests (e.g., fetch) within newSpecPage tests, given the absence of a built‑in mock registry?
\n