In a Playwright component test, what does the mount fixture hand back after it renders a story?

## The call and what resolves from it A Playwright component test is an ordinary test whose callback destructures the `mount` fixture, and the call takes the id of a story you have registered plus the props for that scenario: ```ts const picker = await mount('date-picker-default', { value: '2026-03-14' }); ``` `mount` renders that story on the page you host and resolves to a **`Locator`** for the **root element** of what was rendered. In Playwright 1.63 that locator is the whole test-facing surface of the mounted component. There is no framework component object handed back, no virtual-DOM node, and no hook into the renderer's internals — if you want to know something about the component, you ask the DOM. ## Why a locator rather than an element reference A `Locator` is not a captured node. It is a stored query that Playwright re-runs every time you use it, and that distinction is what makes a component test survive the re-renders a component test exists to provoke. - **Lazy** — nothing is looked up when `mount` resolves; the query runs at the moment you click or assert. - **Re-resolving** — when the component re-renders and replaces its root, the next action finds the new node instead of failing on a detached one. - **Auto-waiting** — actions and web-first assertions retry until the element is ready or the timeout expires, so a component that renders asynchronously needs no sleep. - **Strict** — if the query ever matches more than one element the action fails loudly rather than silently taking the first match. | Handle | What it really is | After the component re-renders | |---|---|---| | The `Locator` from `mount` | a query re-run on every use | still works; resolves the new node | | An `ElementHandle` | a pinned reference to one node | goes stale once that node is replaced | | A framework component instance | not exposed by `mount` at all | not applicable — assert through the DOM | ## The root is a scope, not just a target Because the locator points at the component's root, it doubles as a search scope. Chaining from it — `picker.getByRole('button', { name: '14' })` — searches only inside the mounted subtree. That matters more than it sounds: - A story that renders two toasts side by side stays unambiguous, because each chain starts from its own root. - Chrome that your story page draws around the component (a theme switcher, a padding wrapper) is outside the root and therefore invisible to the chained query. - Strict-mode failures become informative: "two matches inside the data grid" is a real finding about the component, not noise from the rest of the document. ## The two methods that belong to the instance Beyond everything a locator can do, the handle `mount` returns carries two methods that address the mounted instance itself: - `update(props)` re-renders that same instance with new props, keeping whatever state it had built up. - `unmount()` removes the component from the page again. Both are about the *instance*, not about the query. A plain locator you built with `page.getByRole()` has neither. ## How a test typically uses it 1. Mount the story with the props that set up the scenario. 2. Chain locators off the returned root for the parts you care about. 3. Act on those chained locators — click, fill, press. 4. Assert with web-first matchers on the root or on a chained locator. 5. Optionally `update(props)` and assert again, or `unmount()` when the scenario is done. ## What this shape pushes you toward The only handle being a DOM query is a design choice with consequences. You cannot reach in and call a method on the component or read its internal state, so assertions land on what a user can perceive: rendered text, roles and accessible names, attributes, classes, geometry. That is usually what you wanted anyway — a design-system date picker whose internal flag says `open: true` while nothing is visible on screen is broken, and only the DOM-level assertion catches it. It also means the tests do not have to change when the component's internals are refactored, as long as the rendered output stays the same. The cost is that anything with no DOM footprint at all is simply not observable from a mount, and has to be surfaced deliberately by the story before a test can see it.