Blocks
5 blocks for an e-commerce page
An e-commerce page has to sell one product, not show a catalogue. Five categories, the order between gallery and cart, the client-side price faults and the real catalogue counts.
Key points
- Pick the gallery by the photo format, not by the number of thumbnails.
- A cart that computes the price in the browser is not a cart.
- Two cart blocks and four checkout: payment stays outside the catalogue.
An e-commerce page has to sell one product, not show a catalogue. The catalogue indexes 51 hero blocks, 4 gallery, 2 cart, 4 checkout and 45 footer, read on 2026-11-01: five categories for a product page.
The counts come from the category pages, measured on the same day. Two cart blocks and four checkout on 1.556 records say the most important thing about this page: the part that takes the money is not the part the catalogue covers best.
What the page has to do
The buyer has one question: “is this the right product for me, and when does it arrive?”. The page has to show the product large, state variants and availability, put the price next to the button and explain shipping and returns without opening another page. Brand stories, two-minute videos and reviews below the fold are a second job, done after the first question is answered.
- A gallery that holds vertical and horizontal photos without jumping.
- Variants with real availability, not a decorative dropdown.
- Price and shipping cost before the cart click.
- A cart that re-reads the price from the server at order time.
The order of the blocks
| Section | Role on the page | Blocks available |
|---|---|---|
| hero | put the product on stage | 51 |
| gallery | let people see the product up close | 4 |
| cart | summarise the choice | 2 |
| checkout | close the order | 4 |
| footer | give shipping, returns and payments | 45 |
Hero, gallery, cart, checkout, footer. The gallery sits right under the hero because the buyer must see the product, and the cart does not go on top: whoever has not picked a variant cannot fill it, and an empty cart on top is the wrong first impression. Checkout is a separate page in practice, but the block is designed now because it shares fields with the cart.
The blocks to start from
The tables list block, registry, files and category. The 2-file gallery is the lightest and the most limited: thumbnails plus a main image, no zoom. The 1-file cart is a summary, not a cart with quantity and stock: name it that way in the code too, and do not expect it to handle tax computation.
Hero blocks
| Block | Registry | File | Category |
|---|---|---|---|
| Hero 01 - Agency Hero Section | Shadcn Space | 8 | hero |
| Hero 02 - Real Estate Hero Section | Shadcn Space | 6 | hero |
Gallery blocks
| Block | Registry | File | Category |
|---|---|---|---|
| Gallery 01 - Image Gallery Section | Shadcn Space | 2 | gallery |
| Gallery Grid with Lightbox | uitripled | 1 | gallery |
Cart blocks
Checkout blocks
| Block | Registry | File | Category |
|---|---|---|---|
| Checkout 01 - Tabbed Billing Checkout | Shadcn Space | 2 | checkout |
| Checkout 01 | commercn | 1 | checkout |
What breaks in production
The first fault is the price: the cart block sums values in the browser and the total does not match what is charged once a discount or a different regional tax appears. The second is the gallery rebuilding its layout on every image change and moving the buy button. The third is checkout asking for the address before saying what shipping costs.
- Total computed client side: it drifts from the charged price.
- Gallery without dimensions: the buy button moves on every photo.
- Stock not checked: an out-of-stock product gets sold.
- Checkout without a card error: the user sits on a silent page.
curl "https://ui.eneawork.it/api/blocks/category/cart?limit=5"The call returns the available cart blocks with source and files. With only two results the check is quick: if neither accepts a price from the server, the cart gets built from scratch and the catalogue only helps with the visual summary.
A limit to declare
With 2 cart blocks and 4 checkout, the catalogue covers the shop window and not the transaction. Addresses, payment methods, 3-D Secure and order webhooks do not exist here: the product page can be composed, the purchase path cannot. Planning on blocks alone understates the part that costs.
In the catalogue: price block, components and all blocks. The guides: building an e-commerce, pricing tables in 10 minutes and UI library weight.
Frequently asked questions
How many photos does a product gallery need?
Four to six, with at least one scale reference and one close-up. Past six, the buyer stops scrolling. The catalogue block sets no number: the thumbnail grid adapts, but photo quality stays the factor that decides conversion.
Can I use the cart block as a real cart?
Only after giving it external state: rows, quantities and prices must arrive from the server. The 1-file block is a visual summary with static amounts; using it as a cart means rewriting the logic and probably the structure as well.
Is shipping better shown on the page or at checkout?
On the page, next to the price. Whoever discovers the shipping cost only at checkout abandons more often, and the figure belongs there as a range when it depends on destination, with the free-shipping threshold beside it.
Do reviews belong on the product page?
Yes, but below the fold with a summary: count, average score and two quotes. No catalogue block ships a review system, so the component gets built or wired to an external service, and it comes after the purchase part.
How do I verify the cart before going live?
With three test orders: one with a discount, one shipping to another region and one with a declined card. If the shown total differs from the charged one in a single case, the computation sits in the wrong place.