An end-to-end suite has one page object per URL, but the application is built from reusable components — a cart widget, a data grid, a date picker — that appear on many of those pages, and the page objects have started duplicating each other. When would you scope helpers to a component instead of to a page, and what does that change?

## Why page-shaped objects drift in a component app The page object pattern predates component frameworks. Its unit is the *page*, because in a multi-page application the page was the thing that existed, changed and was navigated to. In an application assembled from components, the page is often just a composition — an arrangement of widgets that each have their own owner, their own tests and their own change cadence. When the abstraction's unit disagrees with the application's unit, knowledge gets copied. A sortable grid on the orders page, the customers page and the reports page ends up described three times, in three page objects, by three people. Six months later the three descriptions differ: one waits for a spinner, one does not; one sorts by clicking the header, one by opening a menu that was added later. Nobody chose those differences. That is **drift**, and it is the concrete failure mode this leaf is about. ## Making the component the unit A component-scoped helper is parameterised by *where the component is*, not by which page it happens to be on. It receives a container — a root element for the widget — and every lookup it makes is relative to that root: ```ts class DataGrid { constructor(private readonly root: Locator) {} rows() { return this.root.getByRole('row'); } async sortBy(column: string) { await this.root.getByRole('columnheader', { name: column }).click(); } } ``` The same class now works on the orders page, the customers page, in a modal, and twice on the same screen if two grids are rendered side by side. Two grids in one page object would have needed two sets of methods or a disambiguating parameter; two instances of a component helper need nothing but two roots. ## What the page-level object becomes It does not disappear; it changes job. It stops owning widget internals and becomes a **map of the screen**: navigation to it, the pieces it hosts, and any behaviour that genuinely belongs to the page as a whole (a page-level empty state, a wizard's step order). Instead of forty methods, it exposes a handful of components: ```ts class OrdersPage { constructor(private readonly page: Page) {} get grid() { return new DataGrid(this.page.getByRole('region', { name: 'Orders' })); } } ``` That is a small file, and each part of it points at an owner. ## When it is worth it - **The widget appears on more than two surfaces.** One or two hosts rarely justifies the extra indirection. - **The widget has real behaviour** — sorting, pagination, multi-step interaction — rather than being a styled div. - **The widget is owned by a team or a library.** Then the helper can live next to the component and change with it, which is the closest a test layer gets to being maintained by the people who cause the breakages. ## When it is not - **Superficial similarity.** Two components that look alike but are separate implementations will pull one helper in opposite directions, adding flags until it is worse than two honest copies. Sameness of markup is not sameness of component. - **A page-unique flow.** A one-off checkout wizard is a page-level concern; wrapping each of its panels as a "component" invents structure the app does not have. - **A suite too small to have drifted.** If the widget is touched by three tests, duplication has not cost anything yet. ## The wider point The underlying principle is that a test abstraction should mirror the unit of change in the application. Ask what a typical pull request touches: if PRs change a component and its usages, component-scoped helpers track them; if PRs replace whole screens, page objects track that better. The debate over page objects versus locator-first is at bottom this question — *what is the thing whose knowledge deserves an owner?* — and a component UI usually answers "the component", with the page reduced to a thin composition on top. ## Reuse beyond end-to-end A bonus of the component-scoped shape is that the helper depends only on a root element, not on a URL or a session. That makes it usable wherever the component is rendered — including an isolated component harness — so the same vocabulary describes the widget at more than one test level. That reuse is not free (the helper must not assume application-level context), but where it works it removes a second, divergent description of the same widget.