> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/product/using-peakcommerce/templates/creating-a-component.md).
# Creating a Component
When the system components don't cover a layout you need — a bespoke pricing block, a branded banner, a portal widget specific to your business — you create your own. User components become first-class blocks in the page editor, so a layout you build once can be reused across pages and portals. Create them in **Content → Component Library**.
The component editor — fields on the left, a live preview in the center, and the selected field's properties on the right.
## The fastest path: describe it to Mango
Describing a component to [Mango](/product/getting-started/meet-mango.md) now produces a **native component** — built from the same blocks the page editor uses (headings, text, containers, buttons, lists), not from generated code. That changes what you get in three ways that matter:
* **It's styled by your brand automatically.** Native blocks inherit your tenant's look, so Mango's first draft already matches your pages.
* **Every element stays individually editable.** Afterwards you can select any heading, button, or row and adjust it directly — in the component editor or right on a page — instead of treating the result as one opaque block.
* **It can't be stored broken.** Native layouts are validated at save time; anything that cannot render is refused with the exact problem named, so a component never saves fine and then breaks on a customer's page.
Ask for something close, adjust it by hand, keep the result — that loop is the intended way to work. See [Native components](https://gitlab.com/peakcommerce/peak-help-docs/-/tree/main/developers/native-components.md) for the full picture: the block vocabulary, placeholders and formatters, dynamic lists, and promoting a layout you built on a page with **Save as component**.
## The code path, when you need it
Code components remain for bespoke needs — visual designs the native blocks genuinely cannot express. You write (or have Mango draft) HTML and CSS in the editor's **Code** view, and the component renders exactly what you wrote.
## Two ways to start
* **New Component** — build a component from scratch in the component editor.
* [**Create with Mango**](/product/getting-started/meet-mango.md) — describe what you want in plain language and have PeakCommerce generate a working native component for you, which you can then refine.
## The component editor
The editor is a three-pane workspace:
* **Left rail** — switch between **Insert** (drop in ready-made snippets), **Fields** (define the editable properties authors will see), and **Chat** (ask Mango to generate or change the component).
* **Center canvas** — toggle between a live **Preview** (rendered at desktop, tablet, or mobile widths) and, for code components, the **Code** view for direct editing.
* **Right inspector** — **Props** for the selected field or the whole component, and **Data** for binding the component to live commerce data.
When you ask Mango for a change, it proposes an edit you can accept, reject, or refine; accepting it updates the component — the native blocks or the code, whichever kind it is — together with its fields and the preview.
## Settings to set
* **Category** — how it's grouped in the library.
* **Contexts** — which editors and page types it can be used in (Storefront, Checkout, Customer Portal, Partner Portal, CSR Portal, or Payment Pages). Choose every context where the component should be available.
* **Status** — set it **Active** to make it available in the page editor.
## Things to watch
* **Set the right contexts.** A component only appears in editors whose context you selected — if it's missing from a page, its contexts are the first thing to check. The component editor's placement banner tells you outright when a component cannot appear anywhere, and why.
* **Active is what makes it usable.** A saved-but-inactive component won't show up as a block until you activate it.
* **Define fields for anything authors should edit.** Values you don't expose as fields are baked into the component and can only be changed back in the editor.
Once active, the component appears in the [Component Library](/product/using-peakcommerce/templates.md) and can be placed on any [page](/product/using-peakcommerce/ecommerce-and-payment-pages/adding-an-e-commerce-page.md) whose context matches.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.peakcommerce.com/product/using-peakcommerce/templates/creating-a-component.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
