Skip wishlist lists fetch for guest visitors to reduce CLS on product listings

[Prestaplugins]

Questions	Answers
Branch?	dev
Description?	Guest visitors triggered an unnecessary getAllWishlist fetch via the Apollo lists resolver when wishlist buttons were initialized on product listing pages. This delayed button rendering and caused Cumulative Layout Shift (CLS). This PR short-circuits the lists resolver when prestashop.customer.is_logged is false, returning an empty array without any network request (same login flag already used by Button.vue).
Type?	bug fix
Category?	FO
BC breaks?	no
Deprecations?	no
How to test?	1. Install the module on a PrestaShop 8.x or 9.x shop with product listings. 2. Guest: open a category page → Network tab → confirm no getAllWishlist request. 3. Guest: wishlist buttons still appear on miniatures; clicking opens login modal as before. 4. Logged-in customer: getAllWishlist is still called; add/remove from wishlist works on listings and product page. 5. Optional: run Lighthouse on a category page and compare CLS before/after.
UI Tests	N/A (module JS change; no native UI test campaign run)
Fixed issue or discussion?	Fixes #463
Related PRs	—
Sponsor company	Prestaplugins

Summary

• Skip the lists GraphQL resolver fetch when prestashop.customer.is_logged is false.
• Regenerate public/ bundles via npm run build so every bundle embedding the resolver stays in sync with _dev/.

Motivation

The lists query is only meaningful for authenticated customers. For guests, the server cannot return wishlists, yet the module still performed the HTTP request and waited for the response before stabilizing the wishlist UI on product miniatures.

[ps-jarvis]

Hello @Prestaplugins!

This is your first pull request on blockwishlist repository of the PrestaShop project.

Thank you, and welcome to this Open Source community!

[nicohery]

Thanks 🙏 The fix itself is sound, and the strict === false guard is a good defensive default (safe fallback when the def is missing).

Could you regenerate the bundles via npm run build instead of hand-editing them? Two side effects on public/product.bundle.js:

• a UTF-8 BOM (EF BB BF) got prepended (not present on dev);
• the lists resolver is also compiled into the productslist / addtowishlist / wishlistcontainer bundles, which don't get the guard. Only product.bundle.js is registered on the FO so it works at runtime, but the compiled assets now diverge from the source.

A clean build keeps public/ in sync, drops the BOM, and applies the guard everywhere. Otherwise looks good to me 👍

[Prestaplugins]

Thanks for the review, @nicohery!

I've pushed a follow-up commit that regenerates all public/ assets via npm ci && npm run build, as requested.

The lists guard is now compiled into every bundle that embeds the resolver (product, productslist, addtowishlist, wishlistcontainer, button, create, rename).
The UTF-8 BOM on product.bundle.js is gone.
_dev/ and public/ are back in sync; no more hand-edited bundles.

[nicohery]

Thanks — the rebuild resolves my first point.

One more change: the module already knows the login state client-side — Button.vue uses prestashop.customer.is_logged (line 95). The lists resolver could gate on that directly:

lists: async (root, {url}) => {
  if (!prestashop.customer.is_logged) {
    return [];
  }
  ...
}

That lets you drop the new blockwishlistUserLogged JS def and the PHP change entirely, for a single source of truth.

[Prestaplugins]

Thanks for the follow-up, @nicohery! Pushed a commit that gates the lists resolver on prestashop.customer.is_logged (same flag as Button.vue) and reverts the blockwishlistUserLogged PHP/JS def. Bundles regenerated via npm run build.

[nicohery]

Simplification's in. Approving and leaving the rest to other reviewers.