SFCC — Solving Wishlist Icon Accuracy on PLP & PDP

Explore effective approaches to ensure wishlist icon accuracy on PLP & PDP in SFCC websites.

Legend

• SFCC → Salesforce commerce cloud
• SFRA → Storefront reference architecture
• PLP → Product listing page
• PDP → Product detail page

Background

For developers working with SFCC and SFRA, wishlist is one of the most commonly implemented features across eCommerce projects.

While the community wishlist plugin covers a broad set of use cases — guest wishlists, registered user wishlists, public wishlists and more — it falls short on one commonly required real-world need: accurately reflecting the wishlist icon state on PLP and PDP based on the logged-in customer’s data.

In real-world projects, clients almost always require wishlists to be exclusive to registered customers, with the heart icon on PLP and PDP accurately reflecting what is actually saved in the logged-in customer’s wishlist.

Problem

The community wishlist plugin overrides a few templates to render the wishlist heart icon on PLP and PDP, giving customers the ability to add or remove products from their wishlist.

The add/remove action does its job — it correctly saves the product in the customer’s wishlist on the backend. The problem lies elsewhere.

Since the template rendering the wishlist icon on PLP & PDP is a local include, it is subject to page cache, and on every page load the icon has no awareness of what is actually in the customer’s wishlist — rendering it in whatever default state the cache last held.

Solution

Let’s look at three solutions that address wishlist icon state accuracy for both PLP and PDP.

Solution 1 — Remote Include Wishlist Icon

This approach leverages one of SFCC’s built-in solutions for cache-related issues — remote includes

1. A GET controller endpoint — e.g. Wishlist-AddProductIcon — is created that accepts a product ID via a pid parameter, checks its existence in the logged-in customer's wishlist, and renders the existing wishlist/components/addToWishListButton template with a flag indicating whether the product is in the wishlist or not.
2. The Wishlist-AddProductIcon endpoint is configured with no caching, ensuring it always reflects the logged-in customer’s current wishlist state.
3. The wishlist/components/addToWishListButton template is updated to conditionally render a filled or empty wishlist icon based on the flag received from the Wishlist-AddProductIcon controller.
4. Wherever wishlist/components/addToWishListButton is locally included in PLP & PDP templates, it is replaced with a remote include pointing to the Wishlist-AddProductIcon endpoint like mentioned below

// Before version
<isinclude template="wishlist/components/addToWishListButton" />

// To be version
<isinclude url="${URLUtils.url('Wishlist-AddProductIcon', 'pid', '<product_id>')}" />

While this solution is straightforward to implement and works well for PDP, it comes with a drawback for PLP worth considering:

• Remote include per product: It introduces an additional remote include per product tile on PLP — which can add up quickly depending on the number of products rendered on the page.

It is best treated as a short-term fix, most suitable when the number of product tiles on PLP is relatively small.

Solution 2 — Post Page Load AJAX Call

This approach is built around a backend endpoint that acts as the source of truth for wishlist state on the client side:

1. A GET controller endpoint e.g. Wishlist-GetProductsState is created that accepts an array or comma separated product IDs as query parameters.
2. For each product ID received, the controller checks whether that product exists in the logged-in customer’s wishlist.
3. The endpoint returns a JSON response mapping each product ID to its wishlist status — present or absent.
4. This endpoint is invoked on every action that renders or updates products on the page — including initial page load, sorting changes, refinement updates, load more, and infinite scroll events.

While this solution does address the core problem, it comes with a few drawbacks worth considering:

• Visible icon delay — On every page load, the heart icons initially render in an empty state and only update once the AJAX call completes. Any latency or error in the call means icons remain empty, potentially creating customer confusion.
• Server overhead — This approach exposes an endpoint that must be called on multiple client-side events. On a PLP with a large number of product tiles, this translates to repeated server hits, adding overhead that compounds under high traffic.

Solution 3 — Remote Include Driven Wishlist Data (Preferred solution)

This approach is also built around a backend endpoint, but shifts most of the work to the client side after the initial page load:

1. A GET controller endpoint — e.g. Wishlist-Info — renders an ISML template containing a hidden div whose data attribute holds all product IDs currently in the logged-in customer’s wishlist as a comma-separated list.
2. This endpoint is remotely included within the base page template — e.g. page.isml in SFRA — ensuring it is available across all pages without being subject to page cache.
3. On page load, client-side JS reads the product IDs from the hidden container and toggles the heart icons accordingly across all product tiles on the page.
4. For subsequent actions — sorting changes, refinement updates, load more, and infinite scroll — the same client-side logic runs against the already-loaded wishlist data with no additional server calls required.
5. When a product is added or removed from the wishlist, client-side JS updates the hidden container in real time, keeping the wishlist data accurate for the remainder of the session.

This solution not only solves the core problem but does so efficiently:

• Single server call per page load — wishlist data is fetched once via the remote include and reused entirely on the client side for all subsequent interactions.
• No visible icon delay — since the wishlist data is available as part of the page render, heart icons can be toggled immediately on page load without waiting for a secondary AJAX response.
• Eliminates the drawbacks of Approach 1 — no repeated endpoint calls, no server overhead under high traffic, and no risk of icons remaining empty due to a failed AJAX request.

Thank you for taking the time to read this. I hope it helps you make a more informed decision when implementing wishlist icon state accuracy in your SFCC SFRA projects.

Hope this blog help others!!!