# Element naming

Element naming is the hardest when it comes to standardization for Bubble development. In this document, we covers not just recommendations for element naming but also element types break-down. These types come from creative ways that Bubble developers use the elements to their fullest to demonstrate complex behaviors.

## TL,DR:

### Groups

* Structural groups: Use **Header, Body, Footer, Section** for the corresponding groups.
* Regular groups: Use **`{Group type} {Group name}`** like usual. For example: *Group Testimonials, FloatingGroup Sidebar, Popup Deletion Confirmation.*
* Sub groups: Use **`[{Parent's name}] {Group type} {Group name}`**. For instance:
  * Parent group: **`FloatingGroup Nav`**
  * Sub group: ***`[Nav] Group Menu`***
* RepeatingGroups: Use **`RepeatingGroup {Data type}`** or **`RG {Data type}`**. For instance: **`RG Comment`**.

### Reusable elements

Reusable elements should be named like pages, with type: **`[{Reusable type}] {ReusableElementName}`**. For example: **`[Drawer] UserDetails`**

Common reusable types include:

* Container: A big component that contains a lot of elements and logics inside, similar to an *organism* in atomic design, mainly used for breaking the apps into smaller parts.
  * Drawer: Either a popup or floating group that displays data as a drawer.
  * Dialog: A popup with CTAs.
  * Subpage: For groups used in single-page behavior.
* Workflow: Invisible components that encapsulate workflows only.
* Component: Small components, like a simple like button with logics that manage the number of likes.

### Visual elements

* Non-dynamic elements: You should keep the element type first, and then its name, like usual: **`{Element type} {Name}`**. For instance: *Button Submit Feedback.*
* Dynamic elements: Use **`{Element type} {Data field}`** or **`{Element type} {Operations}`**. For instance: **`Text username`** or **`Text firstName + lastName`***.*

### Input elements

Input elements should reflect the data they are changing: **`{Element type} {Data field}`** or **`{Element type} {Data type/Data field}`**. For instance: **`Input username`** or **`Input User/username`***.*

### Custom states

To differentiate from data field, use **snake\_case** for custom states. Other than that, custom states should be similar to a data field's name.

### **Notation of state, data & clickable**

* **`<S>`** or **`<State>`** for elements with custom states.
* **`<D>`** or **`<Data>`** for elements with custom data sources (parent elements only, no need to mark child elements that inherit the data).
* **`<C>`** or **`<Click>`** for non-input elements that are clickable (e.g. texts, groups).

Example: **`<S> Group Users`**&#x20;

### Notation of element grouping

**`[Tag]`** should be used to group elements together.

### Notation of order

Groups, data fields, option set fields, etc when related to ordering (e.g. steps in an onboarding process, indicated by an option set) should come with a number indicator (`no_`) before the name.

Example: `1_onboardingStep`; `2_onboardingStep`

For further analysis, explanations and examples, please check the below documents out.

{% content-ref url="/pages/TFAhRFk8dg1uq1lTQvu7" %}
[Groups](/bubble-convention/naming-conventions/element-naming/groups.md)
{% endcontent-ref %}

{% content-ref url="/pages/UF7SyOQBDAGCk9j7x2yp" %}
[Reusable elements](/bubble-convention/naming-conventions/element-naming/reusable-elements.md)
{% endcontent-ref %}

{% content-ref url="/pages/lyYtJjctmFGyFavbRZEb" %}
[Visual elements](/bubble-convention/naming-conventions/element-naming/visual-elements.md)
{% endcontent-ref %}

{% content-ref url="/pages/L03KSlauMAkBIcIqS6ur" %}
[Input elements](/bubble-convention/naming-conventions/element-naming/input-elements.md)
{% endcontent-ref %}

{% content-ref url="/pages/8M2ogyVCO2LlbzzptT8A" %}
[Custom states](/bubble-convention/naming-conventions/element-naming/custom-states.md)
{% endcontent-ref %}

{% content-ref url="/pages/wP7413IUYJMwwAm6QxQi" %}
[Other notations](/bubble-convention/naming-conventions/element-naming/other-notations.md)
{% endcontent-ref %}


---

# Agent Instructions: 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:

```
GET https://bubble.citizendev.io/bubble-convention/naming-conventions/element-naming.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.