> 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/guides/feature-guides/build-and-launch/guide-designing-pages-with-mango.md).

# Designing Pages with the Editor and Mango

### Overview

**Pages** are the building blocks of journeys, storefronts, and portals — every journey step renders a page. You compose pages from blocks in the **Component Library**, and when you need a block that doesn't exist yet, you build it in the component editor — by hand, or by describing it to **Mango**, PeakCommerce's AI assistant, and refining what she generates.

This guide walks through building a page from components, creating a custom component with Mango, and the accept/reject flow that keeps you in control of every change.

### Before you begin

* You know which kind of page you're building — **Checkout**, **Storefront**, **Payment**, or **Portal** — because a component only appears in editors whose **context** matches.
* You're an admin who can open **Content → Pages** and **Content → Component Library**.

### 1. Build a page from components

1. Go to **Content → Pages** and click **+ New Page** to start from scratch, or **From Template** to start from a prebuilt layout.
2. Drag blocks from the **Component Library** onto the canvas to lay out the page. Both system components and any custom components you've built (and that match this page's context) are available.
3. Each page has a **slug** — its public path, for example `/s/thank-you`. Set it so the page can be linked and bound to a journey step.
4. **Publish** the page to make it live, then bind it to a [journey step](/guides/feature-guides/build-and-launch/guide-building-a-checkout-journey.md) to use it in a flow.

### 2. Create a custom component — by hand or with Mango

When the system blocks don't cover a layout you need (a bespoke pricing block, a branded banner, a portal widget), build your own in **Content → Component Library**:

* **New Component** — build it from scratch in the component editor.
* **Create with Mango** — describe what you want in plain language — for example *"a three-tier pricing table with a highlighted middle plan"* — and Mango generates a working component (fields, layout, and code) that you can then refine.

### 3. Work in 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 page authors will see), and **Chat** (ask Mango to generate or change the component).
* **Center canvas** — toggle between a live **Preview** (at desktop, tablet, or mobile widths) and 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.

### 4. The Mango accept / reject flow

Ask Mango for a change in the **Chat** panel and she **proposes** an edit — she never applies it silently:

* **Accept** to apply it; the code, fields, and preview all update together.
* **Reject** to discard it.
* **Refine** by replying with more detail and have her revise the proposal.

Every decision is recorded, so your team can always see who changed what and when. The result: the speed of an eager builder with a human always in the loop.

### 5. Set the component's metadata, then activate

Before a component can be used on a page, set:

* **Category** — how it's grouped in the library.
* **Contexts** — every page type it should be available in (**Storefront**, **Checkout**, **Customer Portal**, **Partner Portal**, **CSR Portal**, or **Payment Pages**).
* **Status** — set it **Active** to make it usable.

Once active, the component appears as a block in the page editor for every matching context.

### Tips

* **Set the right contexts.** A component only shows up in editors whose context you selected — if a block is missing from a page, its contexts are the first thing to check.
* **Active is what makes it usable.** A saved-but-inactive component won't appear as a block until you activate it.
* **Expose fields for anything authors should edit.** Values you don't turn into **fields** are baked in and can only be changed back in the editor.

### FAQ

**Do I have to use Mango to build components?**

No. **New Component** lets you build entirely by hand in the three-pane editor. **Create with Mango** is the faster on-ramp when you'd rather describe what you want — and you can mix the two, hand-editing what Mango drafts.

**Will Mango change my component without asking?**

No. Mango always **proposes** a change you **accept, reject, or refine**, and every decision is recorded. Nothing is applied until you accept it.

**Why doesn't my new component appear on a page?**

Two usual causes: it isn't **Active**, or its **Contexts** don't include that page's type. Check both in the component editor.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.peakcommerce.com/guides/feature-guides/build-and-launch/guide-designing-pages-with-mango.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
