## TL;DR

Both encapsulate selectors; page objects group by page, locator functions group by component. For component-based UIs, locator functions (or Playwright fixtures) age better; page objects fit page-based flows.

## Error

```text
(Not an error; an architecture decision. The cost of a bad choice: selector changes scattered across tests.)
```

## Steps

1. Assess the UI: component-based (React/Vue) favors component-scoped helpers; page-based flows favor page objects. Expected: the structure matches the app.
2. For Playwright, prefer fixtures and locator helpers over classic page objects. Expected: idiomatic Playwright.
3. For Cypress, use custom commands or plain helper modules. Expected: no heavy class hierarchies.
4. Keep exactly one place per selector. Expected: a selector change touches one file.
5. Review after 3 months: if helpers are bypassed, simplify them. Expected: the abstraction earns its keep.

## When to use

- Starting a new suite or restructuring.
- Selector duplication is growing.

## When not to use

- Small suites (helpers are overhead).
- You already have a working pattern (do not churn).

## Tool compatibility

- Any framework; Playwright fixtures, Cypress commands.

## Variant phrasings

### Page object model still relevant

Yes for page flows; less so for component UIs.

### Test selector encapsulation patterns

The general topic; one place per selector.

## Why it happens

Raw selectors in tests duplicate knowledge. Encapsulation centralizes it, but the wrong shape creates its own maintenance burden.

## Edge cases

- Deep page-object hierarchies become their own legacy; prefer flat helpers.
- Helpers that hide waits create mystery; keep waiting explicit.
- Generate helpers from components where possible.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sTUWiCM2suIPo0Sxol-6Sg