Skip to main content

Website

Updating the case-study discovery experience

How the website moved its case-study library to a Sanity-backed browsing experience with filters, sorting, search, and deduplicated results.

3 min read

The HoopAI website changed how visitors browse case studies after the exported listing produced duplicate filtered results and left part of the catalog unreachable in the deployed replay. The replacement uses live Sanity records inside the CMS shell, with React state controlling search, facets, sorting, display mode, and progressive disclosure. This was a website publishing and discovery correction. It did not change customer case-study claims or introduce product capability.

The browsing issue we addressed

The earlier passthrough page contained two collection lists for grid and list views in one Finsweet setup. In the deployed runtime replay, filtered results could appear twice and the show-more behavior did not expose every record baked into the alternate view. The Webflow origin behaved correctly during comparison, which placed the defect in the site's replay path rather than in Webflow authoring.

The team chose a CMS listing because patching the exported markup would have hidden the runtime failure and preserved a fragile structure. The new route reads the caseStudy collection from Sanity and renders one controlled result set. React state derives the visible cards from the source records, preventing the same item from entering the result through two parallel lists.

Filters and sorting

The revised interface provides type tabs plus region and company-size facets. Sorting supports date and alphabetical order. Each control changes the same in-memory collection, so the displayed count, cards, and show-more state remain connected. The durable implementation note records the fields used for facets under the case-study company data.

Filters are useful only when their labels and values match the content model. Industry labels received an explicit mapping so stored values display as readable text. Future changes should update the schema, labels, and filtering logic together. Adding a visual option without a stable source field would create a control whose meaning varies between records.

Search and view choices

Search runs alongside the facets and sort order, while visitors can switch between grid and list views. Both views render from the same filtered array. A show-more control reveals additional records without asking a second collection list to maintain its own state. The result is easier to test because every visible item can be traced to one computed set.

The implementation reuses Webflow classes because the Astro CMS shell does not load the inactive Next.js application's Tailwind styling. Page-specific filter styles are embedded with the component where needed. This preserves the site's established visual language while keeping the stateful behavior in the CMS renderer that owns the listing.

Keeping results deduplicated

Deduplication follows from the data flow rather than from a cleanup pass after rendering. One Sanity collection enters one filtering pipeline and produces one set of cards. Verification checked unique results, facet counts, catalog reachability, and display behavior at local preview and deployed stages. The recorded checks covered every available case study at the time of migration.

The engineering lesson extends to other exported listings. When a replayed interaction fails, compare the deployed page with the Webflow source before editing the export. If the origin works, the investigation belongs in the replay or CMS layer. A replacement is justified only when its data path and verification make the original failure structurally less likely.

Topics

Case studiesContent discoveryCMS