page object model vs locator functions: which to use

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

(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