Documentation Components

This guide describes the reusable documentation components available to documentation contributors. These components provide consistent layouts, formatting, and behaviour throughout the Lowgile documentation.

Whenever possible, use these components instead of manually recreating layouts or repeating common documentation patterns.

---

1. Overview pages

Use the OverviewPage component to create category landing pages such as Tutorials, Platform Concepts, or Developer Guides.

The component automatically renders:

• the overview introduction
• the overview summary
• the navigation card grid

Most overview pages only require frontmatter and introductory content.

Example

---
title: Tutorials Overview
description: Learn how to build practical Lowgile applications.
category: Tutorials

overviewSummary:
  sectionLabel: Tutorials
  itemLabel: Tutorials
  prerequisite: Basic understanding of the Lowgile platform
  outcome: Build practical Lowgile applications through guided tutorials
---

<OverviewPage>

Lowgile tutorials...

</OverviewPage>

Best practices

• Keep the introduction concise.
• Configure cards through the sidebar configuration.
• Configure the summary through frontmatter.
• Do not manually create overview layouts.

---

2. PropertyTable

Use the PropertyTable component whenever documenting the configuration of a Lowgile object, screen, component, entity, variable, or workflow element.

PropertyTable automatically selects the appropriate layout based on the number of values supplied.

Supported layouts

Property | Value

Use for simple configuration.

<PropertyTable
  data={[
    ["Name", "request"],
    ["Context", "Input"],
    ["Type", "This.PurchaseRequest"],
  ]}
/>

---

Property | Value | Notes

Use when additional implementation guidance is required.

<PropertyTable
  fullWidth={true}
  data={[
    ["Prefix Icon", "Send", "Properties tab"],
    ["Color", "Primary", "Appearance tab"],
  ]}
/>

---

Property | Value | Action | Notes

Use for procedural configuration.

<PropertyTable
  fullWidth={true}
  data={[
    ["Binding", "screen.request.vendor", "Review", "Connects the control to the entity property."],
    ["Label", "Vendor", "Set", "Displayed above the dropdown."],
  ]}
/>

Standard Action values

Use the following values consistently throughout the documentation.

Action	Meaning
Set	Enter or change the value.
Review	Verify that the existing value is correct.
Update	Replace an existing value.
Leave default	Do not modify the platform default.
Optional	Configure only when required.
Not applicable	The property is not used in the current procedure.

Best practices

• Use PropertyTable for configuration procedures.
• Use Table only for non-configuration data.
• Keep Notes concise and implementation-focused.

---

3. Table

Use the generic Table component for tabular information that is not documenting configuration.

Typical uses include:

• comparison tables
• reference information
• mappings
• matrices
• summaries

Do not use Table for component configuration.

---

4. CalloutBubble

Use CalloutBubble to highlight important information without interrupting the procedural flow.

Choose the callout type that best matches the purpose of the content.

Document each supported callout type here with an example.

---

5. InfoPanel

Use InfoPanel to display grouped metadata or summary information.

Typical uses include:

• overview summaries
• prerequisites
• estimated duration
• outcomes

Avoid using InfoPanel for procedural steps.

---

6. OverviewCardGrid

OverviewCardGrid automatically generates overview cards from the sidebar configuration.

Cards should be maintained through the relevant sidebar configuration rather than manually editing overview pages.

---

7. Engineering Notes

Engineering Notes are intended for documentation contributors only.

Use them to record:

• sidebar data sources
• component behaviour
• implementation notes
• maintenance guidance

Always enclose Engineering Notes inside MDX comments so they are not rendered in the published documentation.

{/*
Engineering Notes

...
*/}

---

8. Design principles

The documentation component system is designed around the following principles:

• Reuse components rather than duplicating layouts.
• Configure behaviour through frontmatter whenever possible.
• Keep documentation pages focused on content rather than presentation.
• Maintain a consistent reading experience throughout the documentation.
• Standardize common documentation patterns using reusable components.