Naming elements in Bubble: Best practice

Questions
1

Following up on my Things I’ve learned… thread, I was thinking of adding another DO that systemizes conventions in naming elements.

Bubble’s auto-naming makes good sense, and I’m not sure how it could be automated in a better way, but as your app grows, it can quickly become messy. I’m using my own system that I try to stick with with varying luck, but I’m sure there are other ways that are better and/or already widespread.

What I do is first state the Element type, followed by comma and a description. Group types I shorten:

Repeating Group: RG: Employees
Group: G: Header
Text: Text: Header

I’m guessing those who work with making templates (such as @levon and his team) have given this some thought. My questions are:

  • Should we try to set up some sort of best practice for naming in Bubble, or do conventions already exist?
  • I’m not a coder myself, but I’m guessing there are naming conventions that are considered best practice in traditional coding that may be worth adoptins
3 Likes
2

Good topic! Here are a few of my general principles. (A few points tie in with naming fields/data types, so I’m including those)

  • Start with element type name first-description (ex. Popup-User_Edit - similar to your approach, keeps the Element tree menu much cleaner)
  • Even though Bubble allows special characters in naming of things, I steer away from using them. (Ie. never use “?” for something like “Admin?” …instead, use is_admin)
  • Use lowercase by default (especially for naming states and parameters).
  • When creating a series of things (ex. a group of tabs, I name as Group-Tabs-1-Employees_List). (Where “1” is the state value that shows that tab).
  • Always join strings of words together (for field names, parameters, custom states) using a “_” and no other special characters within. (Also makes it easier for selecting all the text at once).
2 Likes