fix(explore): reset scroll position when category filter changes - #887
fix(explore): reset scroll position when category filter changes#887Rafiat30 wants to merge 4 commits into
Conversation
|
@Rafiat30 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
|
Auto-review failed (API error). Leaving PR for human review. |
1 similar comment
|
Auto-review failed (API error). Leaving PR for human review. |
|
good investigation in the PR body (correctly identifying that the original issue text pointed at CausesClient), and the fix plus the integration test with the userEvent flow is tidy. one small ask, non-blocking:
gate: branch is behind main; rebase and rerun CI, then good to merge. |
Switching the active category previously left the viewport at its prior scroll offset, which could strand users deep in a now-stale list. Scroll back to the top whenever activeCategory changes. Refs Iris-IV#561
Adds regression coverage for the scroll-to-top-on-category-change fix:
confirms window.scrollTo({ top: 0 }) fires when the active category changes
and the filtered list updates, and confirms it does not fire again for a
re-click of the already-active category (no-op state change).
Refs Iris-IV#561
The scroll-reset effect fired on first render as well as on actual category changes, which could fight the browser's scroll restoration when navigating back to /explore. Skip the first run with a ref so it only fires on real category changes.
- Format useMultiSigProposals.test.tsx (Prettier check was failing on it) - Add missing Causes.listView/mapView translation keys (en, es) — the view-toggle buttons on /causes reference these keys but they were never added, so next-intl throws MISSING_MESSAGE and the Playwright smoke test fails when it navigates through that page - Add the missing getAllCampaigns mock to the AppPageComponents contractClient mock, and cover the two HomeClient stats/CTA branches that were never exercised as a result (queryFn was undefined, so the stats panel and the wallet-connecting CTA state never rendered) None of this is related to this branch's actual change; main's CI was already failing on all three checks before this branch rebased onto it.
9faeace to
5ebecd0
Compare
|
Auto-review failed (API error). Leaving PR for human review. |
|
@ogazboiz pls help review. i have fixed every issue |
|
this is verified and approved, but today's merge wave put the branch into conflict before it reached the front of the queue (lots of prs touching the same i18n and test files landed at once). please rebase onto current main and push, i'll merge as soon as it's green, no re-review needed. |
3 participants
Closes #561
Summary
ExploreClient.tsxhas no search box, URL params, or cursor-based pagination — it's a client-side category-pill filter overuseCampaigns(). The pagination/cursor reset issue as originally described actually lives againstCausesClient.tsx, which already resets its page state (visibleCount) on every filter change. The remaining gap inExploreClientwas UX-adjacent: switching categories didn't reset scroll position, so users could be left stranded deep in a now-stale list.Changes
src/app/[locale]/explore/ExploreClient.tsx— scrolls back to the top of the page wheneveractiveCategorychanges.How to test
/explore.npm run typecheck