Quick View and In-Grid Add to Cart on Shopify

Definition

Adding to cart without leaving the grid: quick-view modals rendered through the Section Rendering API or an alternate product template, in-card variant pickers and size pills, and quick-add flows that block the add until an option is chosen. The cart request still carries a variant id, so the choice a product page would ask for has to be made in the card or in the modal.

The Evidence

• Evidence strength: 12 live, Deploi-attributed builds across 3 Shopify storefronts.
• Split by storefront: Nudestix 6, Three Ships 4, LUS Brands 2.
• Split by attribution: 7 Deploi-authored, 5 modifications of vendor theme code — named as such on each build page.
• Evidence quality: 3 carry code plus client working records. 9 are documented from the code; no client-side record of the decision survives.
• Confidence: 2 strong, 10 moderate. On most of this page we are reconstructing reasoning from the theme, not quoting a recorded decision.
• Surfaces: the homepage, collection listings and landing pages in roughly equal measure, then the product page. One build runs wherever a card renders.
• Status: Live, verified 2026-09-07. Buy-vs-build verdict: built every time, with no decision page to link — see below.

How It's Actually Built

Start with the platform fact every build here answers. A card renders a product; a cart takes a variant. Dawn's card-product with its quick_add setting bridges the two one way: a button that opens a modal, or a straight post for a single-variant product. This page is what happens when a storefront needs that bridge somewhere the theme didn't put it, or needs it to end somewhere other than the cart. What we found is not one component but the same affordance built at four layers, and the layer is decided by what the shopper has to choose before the add is legal.

The section layer: a quick view is a second rendering of the product section. Stock Dawn fetches the product page and lifts its main section into a <quick-add-modal>; Nudestix's cards fetch /products/<handle>?view=quickview instead — an alternate template whose main section is the product section — and land that. Alternate views are the whole trick: what comes back is the product page's own render, so the shade row, that shade's media and the copy are the ones the product page would show, and nothing has to be modelled a second time. Three Ships reaches the same place from the vendor's side: the premium theme's product snippet takes a section-type parameter, and quickview renders the buy-box form inside a modal.

The card layer: a real product form inside the card. Where a rail needs add-to-bag without a modal, the card carries {% form 'product' %} wrapped in Dawn's <product-form>, so the add posts through the theme's own AJAX cart and every cart-aware component hears it. LUS Brands' homepage rail does that from a card of its own, de_fc_product_card.liquid. Nudestix's tutorial rail does it from card-product-video.liquid, with a <variant-radios> shade row bound to the form beside a <modal-opener> — a single-shade product adds from the card, a multi-shade one once a shade is picked. LUS's kids rail renders Dawn's card-product unchanged and passes the section's quick_add setting through.

The document layer: one listener, no card binding. Three Ships' cards are rendered by a paid vendor theme and arrive from many sections, some after load. So the size picker is one click listener on document, registered in the capture phase. It recognizes a card by attribute contract — [data-pgi-product-id], .pgi-size-pill with data-variant-id, [data-pgi-variant-input] — writes the chosen variant into the form, and intercepts the theme's own add with stopImmediatePropagation() until a size is chosen. The add posts FormData to /cart/add.js and dispatches both cart:refresh and cart:updated, because two carts listen on that storefront.

The dependency layer: who loads the scripts. Dawn enqueues quick-add.js and product-form.js only from sections that already render quick-add cards. A custom section on a page template has neither, so the tutorial rail enqueues its own. The kids rail gates the same assets on its quick_add setting: nothing for none, the stylesheet and variant picker for standard, the four-script set for bulk. Quick add is a contract with a payload, and the section that wants it carries the payload.

The Buy-vs-Build Position

The corpus's own verdict on this capability:

Built on the Section Rendering API every time — the platform gives this away, yet it remains a common paid app category.

There is no Build-vs-Buy decision page for quick view, and that is the honest position rather than an omission: across 12 builds there is no app attempt to compare against. Read "Section Rendering API" in that verdict broadly. What the platform gives away is a server render fetched on demand — an alternate template through ?view=, a section through its id — and every quick view here is one of those, so the modal shows the product the way the product page does.

Quick-view and quick-add apps do a real job: a modal, a picker and a cart call without a theme deploy. What they do it with is a card or modal re-rendered from their own API, in their own markup, through their own cart layer — so your badges, your shade rules and your cart events get taught a second time. Here the card, the form and the cart are the theme's.

The Builds

Five of the 12 have published pages. Two of the remaining seven won't get pages of their own: one is folded into a build page already published here, and one was pulled at editorial review. The other five are documented in the corpus — a collab-page module with a quick-add product carousel, a stripped tutorial card that routes every product through quick view, the theme's quick-add modal extended with a gallery and a builder hook, and two card and module builds on the premium theme.

Nudestix

• Featured tutorial with an adjacent shoppable product rail — three cards beside a deferred video, each with a modal path and an in-card form, on a page template that loads its own quick-add scripts. Medium complexity, landing.

Three Ships

• Size-pill variant picker and quick add-to-cart inside product grids — one capture-phase listener that turns pills into a variant selector and blocks the add until a size is chosen, on cards a widget injects as well as the theme's own. Medium complexity, every grid surface.
• Configurable PDP block system on the Palo Alto theme — the vendor's product snippet given a quickview section type that renders the buy-box form in a modal. High complexity, product page. An extension of Palo Alto 5.8.0 by Presidio Creative, a paid premium theme, not authorship of it.

LUS Brands

• Merchandisable homepage product carousel with a tag-driven badge engine and inline add-to-bag — a hand-picked rail whose card carries its own <product-form> posting through Dawn's cart. High complexity, homepage.
• Kids featured collection: a custom element that builds its Swiper on approach and wraps the theme's own product cards — Dawn's card-product unchanged, with the quick_add setting deciding whether cards add in place and which scripts that costs. Medium complexity, homepage and about page.

What This Rests On

• Liquid section schema and settings — the most-used primitive here; on the kids rail, whether cards can add at all is a section setting.
• Cart AJAX API — where every in-grid add lands, through Dawn's <product-form> or a direct FormData post to /cart/add.js.
• Metafields — card imagery, hover media and the subtitle that travels into the palette panel's payload.
• Section Rendering API — how cards arrive after load on the premium theme, and why the picker there is delegated rather than bound.
• JSON templates — product.quickviewbundle and product.quickview: an alternate template is what turns a product section into a panel.
• Custom elements — <product-form>, <quick-add-modal>, <variant-radios>, <kids-featured-collection>.
• Theme blocks — hand-picked products as blocks on the LUS rail; the product page's block set carried into the quick-view render.
• CSS custom properties — pills that borrow the vendor theme's outline-button tokens; a sub-brand rail scoped per section id.
• Swiper — the slider library most of these rails wrap; Rebuy, Wishlist Hero and Yotpo share the card's DOM.

What Varies by Storefront

Theme base decides which layer is available. LUS Brands runs Dawn 15.4.1, whose card-product already supports quick_add, so the kids rail passes the setting through and the work is asset gating; the adult homepage rail chose a card of its own because its badge vocabulary didn't belong in the shared one. Nudestix runs Dawn 6.0.2, nine major versions older, where the quick view is a ?view=quickview fetch into a <quick-add-modal> and the cards are local forks. Three Ships runs Palo Alto 5.8.0 by Presidio Creative, a paid premium theme whose compiled bundles aren't editable in the theme, so the size picker sits above the cards rather than in them, and the quick view is the vendor's product snippet in a third mode.

Catalog shape decides what the shopper has to choose. Color cosmetics means the unit is the shade, so a Nudestix card can't add without a shade row, and the quick views there carry the product page's own picker rather than a summary of it. Skincare in two sizes means the unit is the size, so a Three Ships card gets pills and a blocked button. Haircare merchandised as kits and hero SKUs mostly adds from the card directly, so the LUS rails are about the card rather than picking inside it.

The installed stack sets the last difference. On one storefront a recommendation widget injects cards after load and a second cart listens for adds, so the handler is delegated and fires two event names. On another a wishlist button mounts inside the palette panel in its own form, so wishlisting works where buying doesn't.

Where This Gets Hard

The add is the easy part; the variant is the hard part. Shopify's cart takes a variant id, and a card that adds before the shopper has chosen one has added the wrong thing. Every build here solves that once — a blocked button, a shade row, a modal — and each solution has to stay in agreement with the product page's rules about sold-out variants and selling plans. A quick view rendered from the product section inherits those rules. A card that carries its own form does not, and it drifts.

Ownership of the scripts is the second cost. Quick add on Dawn is a set of assets the theme enqueues from specific sections, so a section that wants quick-add cards on a page template Dawn never wired declares them itself — and a second such section on the same page declares them again.

Two card renderers in one theme is the cost that compounds. Once a rail has a card of its own, every change to card behavior — a badge, a rating mount, a sold-out state — is made twice. The kids rail on LUS takes the other route: it renders the theme's own card and owns only the dependencies, so a change to the grid's card reaches the rail on the next render. Delegation has its own tax: a capture-phase listener on document sees every click on the page.

So there are storefronts we'd tell not to build this. If your catalog is mostly single-variant products on a recent Dawn, card-product with quick_add on already does the job. If the choice a shopper has to make is genuinely the product page's — a subscription option, a size guide, a kit's contents — a modal is hiding something they need, and the honest answer is a good product page one tap away. And if a widget you don't control renders your grid, a delegated handler is the right shape, but only if someone on your side knows it's there.

Related Capabilities

• Collection merchandising: rails, tiles and in-grid promotion — the rails these cards sit in, argued from the merchandising side.
• Variant swatches and shade pickers — the picker on the product page, reduced to a size pill on the card.
• Fixed bundles and kit merchandising — where the same alternate-view fetch turns up again, inside a kit module's drill-down.
• AJAX cart drawer and line-item rules without an app — the cart every in-grid add reaches, and the events it has to hear.
• Video and shoppable media modules — the deferred embed the tutorial rail sits beside.

Answers to Help You Make Smart Decisions

Do I need a quick-view app on Shopify? Usually not. Dawn's product card already opens a quick-add modal by fetching the product's own section, and any section can render the product section a second time for a modal of its own. What an app adds is a modal rendered from its own API, in its own markup, with its own cart call — a second copy of your product page to keep in step with the first.

Can a grid card add a product that has variants? Only once the shopper has chosen one; a card that does otherwise adds the wrong thing. The honest options are a picker on the card — a shade row or size pills — with the add blocked until a choice is made, or a modal showing the product page's own picker. We did both here, depending on whether the choice needs the product's imagery to make.

What's the difference between quick view and quick add? Quick view renders the product — imagery, options, copy — in a modal without navigating. Quick add posts a variant to the cart from where the shopper already is. A single-variant product needs only the second; a product with shades or sizes needs the first or an in-card picker. Both have to reach the theme's own cart, so everything listening hears the add.

Can a quick view add to something other than the cart? Yes, if the quick view is a rendered product section rather than a JSON payload. On one storefront a kit module opens a drill-down that fetches the component product through an alternate view and lifts its markup into a modal, while the add at the end of the flow still posts the kit's own variant. Once the panel is a real render, the surrounding page decides what to do with the pick.

Ready to Sell From the Grid Instead of the Product Page?

If your collection cards send shoppers away to make a choice they were ready to make in place, the gap is a form and a binding, not a redesign. Contact us today and we'll show you which layer in-grid add belongs at on your theme.