Skip to content

Exported Properties and Functions

Overview

Exported declarations are the public API of a custom component. By marking a declaration as exported, you make it configurable from the outside — consumers can pass in values, bind data, and wire up callbacks without ever opening the Component Editor.

This page covers both perspectives: how the component author exports declarations, and how the consumer configures them in the Properties view.

What You Will Learn

  • How exported declarations appear in the Properties view when a component is used
  • How to set values for exported properties using the expression editor
  • How to wire up exported function bindings and pass parameters

When To Use This

Use this page when you are creating a custom component and need to make its properties configurable by consumers, or when you are placing a custom component and need to configure its exported properties and wire up event handlers.

Author Perspective: Exporting Declarations

Declarations are exported from the Declarations panel in the Component Editor. Check the Export checkbox when creating a declaration, or right-click an existing one and select Configure Declaration to update it at any time.

The export options — Export Type (One Way / Two Way), Data Type, Default Value, Enumeration Options, and Parameters — are all configured here. For the full reference, see Declarations — Exported Declarations.

Consumer Perspective: Configuring Exported Properties

When you place a custom component on a page or inside another component and select it, its exported declarations appear in the Properties view under a section named after the component. This section appears at the top of the Properties view, above the common element properties.

Property names are displayed in a prettified format. For example:

Declaration name Displayed as
orderId Order Id
inputValue Input Value
user User

Setting Property Values

How an exported declaration appears in the Properties view depends on its type and, for Property declarations, its Data Type. The table below shows the controls available for each combination.

Declaration type Controls in Properties view
Array Expression icon only; write an array expression, e.g. [1, 2, 3]
Object Expression icon only; write an object expression, e.g. { key: 'value' }
Property — Any Expression icon only
Property — Text Edit icon (opens text input) + expression icon
Property — Number Edit icon (opens number input) + expression icon
Property — Boolean Checkbox (always visible) + expression icon
Property — Color Color picker (always visible) + expression icon
Property — Enumeration Edit icon (opens dropdown of configured options) + expression icon
Function Edit icon (opens function picker) + expression icon

The expression icon is always available and opens the Expression Editor, where you can enter any valid JavaScript expression. The edit icon or inline control provides a simpler direct-value experience without writing an expression.

The controls are the same regardless of whether the property's Export Type is One Way or Two Way. The difference is in the binding behaviour at runtime: a Two Way binding will propagate changes made inside the component back to the expression source.

Setting Function Bindings

For exported Function declarations, the edit icon opens a dropdown listing all function declarations available on the current page or component. Select a function to wire it up — Bellini generates the binding expression automatically and populates it in the expression editor.

For example, selecting handleSendOrderRequest for an On Send Order property generates:

1
$ctrl.handleSendOrderRequest()

If the exported function declares parameters, they appear in the Parameters tab of the expression editor. You can pass them through to your function by including them in the call:

1
$ctrl.handleSendOrderRequest(orderId)

This lets the component communicate data back to the page — for example, passing the selected item, a form value, or a status code — so the page function has the context it needs to respond.

You can also click the expression icon directly to write the function binding expression by hand.

Best Practices

Name declarations clearly. Declaration names are prettified directly into the Properties view label — orderId becomes "Order Id", onSendClick becomes "On Send Click". There is no separate display name field, so a descriptive camelCase name is the only way to give consumers a readable label.

Choose a specific Data Type over Any. Setting a concrete Data Type (Text, Boolean, Enumeration, Color) gives consumers a purpose-built editor and prevents misconfiguration from the start. Reserve Any for properties that genuinely need an arbitrary expression.

Use Two Way binding sparingly. Two Way is appropriate when the component itself mutates the value — for example, an input component that writes back to a form field. For most properties, One Way is the safer and more predictable choice.

Set Default Values. A sensible default means the component works out of the box without requiring every consumer to configure every property before it renders correctly.

Export only what needs to be configurable. Declarations that exist purely as internal implementation details should not be exported. A smaller, well-defined public API is easier to document, easier to consume, and less likely to break across changes.

Document all exported declarations. The description you add to a declaration is shown as a tooltip in the Properties view — it is often the only guidance a consumer has without opening the Component Editor. Short descriptions are especially valuable for exported functions, where parameter names alone may not convey expected values or behaviour.

Use descriptive function parameter names. The parameter names you enter in the chip-list are displayed to the consumer in the expression editor. Names like orderId or selectedItem communicate intent clearly; generic names like arg1 do not.

Helpful Resources