Feat/zipcode soft refresh query allowlist#760
Conversation
…clear Co-authored-by: Cursor <cursoragent@cursor.com>
…clear When vtex.delivery-promise-components clears the `page` query param through render-runtime after a location change, the useFetchMore reducer was left on the stale page. A shopper on page 5 would see page-1 results but the next "load more" fetched page 6. Detect the external transition (`runtimeQuery.page` going absent/1 while the reducer is past page 1) and dispatch RESET so the next "load more" correctly fetches page 2. Shopper- driven "load more"/"fetch previous" and initial mount are unaffected. Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
With enableLazySearchQuery on and maxItemsPerPage > 18, SearchQuery fetches the first 18 items and lazily loads items 18..N-1 once. An external refetch (vtex.delivery-promise-components location change) resets the Apollo cache to the initial 18-item window, but lazyItemsRemaining was already consumed at mount — items 18..N-1 would never be fetched again, leaving a permanent gap before the next "load more" page. The new useLazyItemsRearm hook detects the cached list shrinking back to (or below) the initial window while on the first page and resets lazyItemsRemaining, re-triggering the existing 500ms lazy-refill effect. Guards prevent false positives on initial mount, list growth, empty lists, and pages past the first. Co-authored-by: Cursor <cursoragent@cursor.com>
|
Hi! I'm VTEX IO CI/CD Bot and I'll be helping you to publish your app! 🤖 Please select which version do you want to release:
And then you just need to merge your PR when you are ready! There is no need to create a release commit/tag.
|
|
Beep boop 🤖 I noticed you didn't make any changes at the
In order to keep track, I'll create an issue if you decide now is not a good time
|
chrsmutti
left a comment
There was a problem hiding this comment.
I'm not very familiar with the lazyItems stuff, but it looks right! Just have a nitpick on the Changelog.
| rerender({ ...baseProps, page: 5 }) | ||
| }) | ||
|
|
||
| expect(result.current.nextPage).toBe(6) |
There was a problem hiding this comment.
🟡
Shouldn't this be 7? 🤔
|
|
||
| ### Fixed | ||
|
|
||
| - `useFetchMore` (gallery "load more"): the in-memory pagination reducer now resets to the first page when the `page` query param is **externally** brought back to page 1 (e.g. `vtex.delivery-promise-components` clearing it through render-runtime after a zipcode / pickup-point change). Previously, because the reducer is seeded once at mount and only resets on `query`/`map`/`orderBy`/`priceRange` changes, a location change left it on the stale page: a shopper on page 5 would see page-1 results but the next "load more" fetched page 6 (and the URL showed `page=6`). The reset fires only on an external transition to the first page while the reducer is past it, so the shopper's own "load more"/"fetch previous" navigation and initial mount are unaffected. |
There was a problem hiding this comment.
🟡
I'd prefer to make this cleaner, single sentences. And move the "Why?" to the PR description.
What problem is this solving?
How to test it?
[Workspace](Link goes here!)
Screenshots or example usage:
Describe alternatives you've considered, if any.
Related to / Depends on
How does this PR make you feel? 🔗
