Action Metadata and Behavior
Use this section to understand how UI components use metadata to trigger behavior in the Doctor App. Action metadata enables consistent, declarative behavior across screens without writing custom JavaScript.
Why Use Action Metadata
Action metadata allows you to configure component behavior declaratively. This approach improves scalability, simplifies maintenance, and enhances testing consistency across the app interface.
Use action metadata to:
- Trigger navigation or runtime actions.
- Display banners, popups, or external browser windows.
- Connect UI inputs to server endpoints without custom logic.
- Reduce imperative code while maintaining predictable behavior.
Benefits include:
- Simplified onboarding for developers.
- Centralized behavior configuration.
- Consistent interaction patterns.
- Reduced duplication of logic across components.
Metadata Structure
Configure components using metadata fields that define their behavior. These properties enable UI responses based on user interaction or screen state.
Action Properties
Property | Type | Default | Description |
---|---|---|---|
action | string | — | The action type to trigger when the component is activated. |
argument | string | None | A parameter passed to the action, such as a URL or data key. |
autostart | boolean | false | Automatically runs the action when the component renders. |
close | boolean | false | Closes the parent container or popup after the action completes. |
banner | string | None | An optional message to display after the action finishes. |
Supported Actions
Use these action types to implement behavior based on metadata alone.
ID | Action | Category | Requires argument | Description |
---|---|---|---|---|
1 | browser | General | Yes | Opens a browser tab at the specified URL. |
2 | copy | General | Yes | Copies the provided text to the clipboard. |
3 | permission | General | Yes (CSV) | Requests runtime permissions, such as camera or location. |
4 | page | Server | Yes | Loads a new screen using a GET request. |
5 | popup | Server | Yes | Opens a modal popup from a GET request. |
6 | patch | Server | Yes | Sends a PATCH request to update backend data. |
7 | location | Server | Yes | Sends a POST request with device coordinates. |
8 | save | Server | Yes | Submits form data via POST to a backend endpoint. |
9 | camera | Video | No | Toggles the device camera on or off. |
10 | flip | Video | No | Switches between front and rear cameras. |
11 | mute | Video | No | Toggles the microphone mute state. |
Example: Metadata Configuration
The following metadata defines a component that automatically loads a country list and displays a popup on screen load:
{
"type": "combo",
"label": "Select Country",
"action": "popup",
"argument": "/v3/countries/list",
"autostart": true,
"close": true,
"banner": "Country list loaded."
}
This configuration:
- Loads the country list on screen load.
- Displays the selection as a popup.
- Closes the popup after completion.
- Shows a confirmation banner.
Field Type Compatibility
This table outlines which component types support each metadata feature:
Type | Category | Supports List | Supports Range | Supports Events | Examples |
---|---|---|---|---|---|
Field | Text | — | — | — | Email, Phone, Password |
Dropdown | Field | ✅ | — | ✅ | Combo, Multiselect |
Range | Field | ✅ | ✅ | — | Integer, Date, Time |
Placement Reference
Use the placement
and reference
fields to control layout positioning within the screen structure.
Placement Behavior
placement
: Defines the layout depth (e.g.,D-1
for top-level placement).reference
: Anchors the component within a named container.
Example
{
"placement": "D-1",
"reference": "filter-section"
}
This example places the component at layout level D-1
, inside the container named filter-section
.