When a Component Should Be a Template, Not a Canvas Element
An editor team is building a product detail page. They have been assembling it entirely in the layout canvas: a hero, a two-column spec section, a tabbed feature area, and a related-products grid. After several weeks, they report that every new product page requires manually rebuilding the same structure, that small inconsistencies creep in between pages, and that a change to the shared header of the spec section must be repeated on every page. They ask whether they should keep using the canvas or switch approaches. They still need per-product content to vary.
1. Explain the distinction between using the layout canvas for page assembly and using a template, and recommend an approach for this case.
Read the worked answer
The layout canvas is for composing a specific page from components - flexible, editor-driven, but repeated manually per page. A template defines a reusable structure with editable regions/slots, so the shared scaffolding is built once and content varies per instance.
Recommendation: move the repeated structure into a template. The product detail page has a stable skeleton (hero, spec section, tabs, related grid) with variable content (product name, specs, features, related items). That is exactly the template use case. Editors then fill slots per product instead of rebuilding the skeleton.
Judgement: choose canvas for one-off or highly bespoke pages; choose templates when the structure repeats and only content changes. The symptom here - repeated manual rebuilds and drift between pages - is the signal that the structure belongs in a template.
2. How would you structure the template so per-product variation is preserved without reintroducing drift?
Read the worked answer
Structure:
- Template owns the fixed regions: hero layout, two-column spec grid, tab container, related-products region.
- Editable slots inside the template accept the variable content: product hero content, spec rows, tab labels/panels, and the related-products source (e.g., a view or component that queries by product).
- Shared sub-components for the spec header and tab chrome so a change is made once and inherited everywhere.
- Constrained slot options so editors can vary content but not break the structure (e.g., approved layouts for the spec section).
This keeps the skeleton consistent (one place to change the spec header) while letting each product supply its own content. The judgement is to separate structure from content and enforce that separation through the template's slot design.