# Research: Library Pagination UI

## Decision: Angular Router query params for URL state

**Decision**: Use `this.router.navigate([], { queryParams: { page: n }, queryParamsHandling: 'merge' })` for page navigation and `snapshot.queryParamMap.get('page')` on init.

**Rationale**: The library component already uses Angular Router for `?tags=` query params (added in feature 007). Extending the same pattern to `?page=` is the natural fit and keeps a single source of truth in the URL. The `queryParamsHandling: 'merge'` flag ensures that navigating to a new page does not erase the active `?tags=` filter, and vice versa.

**Alternatives considered**:
- Component-local state only (no URL): rejected — FR-008 requires bookmarkable URLs
- `queryParamsHandling: ''` (replace): rejected — would erase `?tags=` param when changing pages

---

## Decision: Replace `loadMore()` with `goToPage(page: number)`

**Decision**: Remove `loadMore()`, `hasMore`, and the append pattern. Replace with `goToPage(n)` that sets `this.images = []` and loads from `offset = (page - 1) * limit`.

**Rationale**: The spec requires discrete pages (FR-001, FR-006). Keeping `loadMore()` alongside pagination would create conflicting UX. Clean removal is simpler and avoids two code paths.

**Alternatives considered**:
- Keep `loadMore()` as a fallback: rejected — two navigation patterns in one view is confusing

---

## Decision: No new dependencies

**Decision**: Implement using existing Angular Router, HttpClient, and CDR. No pagination library imported.

**Rationale**: The pagination logic is trivial (previous/next buttons, a counter, clamped page index). Pulling in a library for two buttons and a text label adds bundle weight and a dependency for no meaningful gain.

**Alternatives considered**:
- `ngx-pagination`: rejected — overkill for two-button prev/next pattern