Fix paginationConfigs type in useCioPlp to match CioPlpGrid

[esezen]

Pull Request Checklist

Before you submit a pull request, please make sure you have to following:

• I have added or updated TypeScript types for my changes, ensuring they are compatible with the existing codebase.
• I have added JSDoc comments to my TypeScript definitions for improved documentation.
• I have added tests that prove my fix is effective or that my feature works.
• I have added any necessary documentation (if appropriate).
• I have made sure my PR is up-to-date with the main branch.

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no API changes)
• Documentation content changes
• TypeScript type definitions update
• Other... Please describe:

What's up

Tiny follow-up to #230 (CDX-425). That PR added useAnchors on PaginationProps and updated CioPlpGridProps.paginationConfigs to use Omit<PaginationProps, 'totalNumResults'> — but the twin declaration on UseCioPlpProps got left on the old UsePaginationProps type. So if you use the headless useCioPlp hook directly and try to pass paginationConfigs={{ useAnchors: true }}, TS yells at you even though <Pagination> happily accepts it.

This bumps useCioPlp's paginationConfigs to the same type so the two public surfaces match. Also copied over the JSDoc bit about useAnchors / the v2 deprecation note from CioPlpGrid so IntelliSense stays consistent.

Notes

• Type-only change, no runtime impact. PaginationProps is a strict superset of UsePaginationProps (just adds optional useAnchors), so nothing breaks for existing consumers.
• No new tests since there's no new behavior — the useAnchors runtime path is already covered by the Pagination specs added in [CDX-425] Add seo friendly anchor based pagination #230.

[Copilot]

Pull request overview

This PR aligns the public paginationConfigs type exposed by the headless useCioPlp hook with the CioPlpGrid component, so consumers can pass useAnchors (added in #230) without TypeScript errors.

Changes:

• Update UseCioPlpProps.paginationConfigs to Omit<PaginationProps, 'totalNumResults'> to match CioPlpGrid.
• Add JSDoc documentation for useAnchors / v2 deprecation note to keep IntelliSense consistent.
• Remove the now-unused UsePaginationProps import from useCioPlp.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Mudaafi]

good catch!

[Mudaafi]

lgtm just some code placements

[Mudaafi]

same as above

[esezen]

Aye aye captain 7caa1df

[constructor-claude-bedrock]

Code Review

This PR fixes a type mismatch between UseCioPlpProps.paginationConfigs and CioPlpGridProps.paginationConfigs by upgrading the former to use Omit<PaginationProps, 'totalNumResults'>, and adds integration tests verifying paginationConfigs forwarding.

Inline comments: 3 discussions added

Overall Assessment: ⚠️ Needs Work

[constructor-claude-bedrock]

Suggestion: mockPagination.mock.calls[0][0] is fragile — it asserts against the first call, but the Pagination component may render multiple times (e.g. initial render before data loads, then after). If a render cycle changes, this index silently tests the wrong invocation. Prefer mockPagination.mock.lastCall[0] or collect all calls and assert the last one:

const lastCallProps = mockPagination.mock.calls[mockPagination.mock.calls.length - 1][0];
expect(lastCallProps).toEqual(expect.objectContaining({ useAnchors: true, windowSize: 7 }));

This applies to both the CioPlpGrid-level and CioPlp-level tests.

[constructor-claude-bedrock]

Important Issue: This test passes paginationConfigs at the <CioPlp> level and asserts that the <Pagination> component receives those props. However, <CioPlp> forwards paginationConfigs to <CioPlpGrid>, which then spreads it directly onto <Pagination> — it does not flow through useCioPlp. This test therefore does not validate the scenario described in the PR description (a user calling useCioPlp({ paginationConfigs: { useAnchors: true } }) directly from the headless hook). A dedicated test for the headless hook path (e.g. a useCioPlp.test or a CioPlp test that renders custom children using the hook) would be needed to prove the type fix has the intended runtime effect.