Hello all !
How do you do for Elements Naming ? For example, I saw some people add emoji to identify element’s type. But for element’s name, some advice to facilitate dev ?
I personally just name what the element does or what it holds.
Example: I have many groups within a group used to send user inputted system emails. There’s a group of inputs that the users uses to write the email, there’s another group to review before sending. All held within a group.
I’d name the group holding the other two groups: Email Module, then the group holding all the inputs: Email Message then review email as: Review Email
2 Likes
I use:
G - group
RG - repeating group
B - button
etc…
All groups with an important responsiveness setting, workflow trigger or condition has an intuitive/relevant name. All others are left empty because I manage things by exception and can always click on the editor and reveal it in the elements tree.
All custom states on the page
4 Likes
I’m building a native app, so I have a single page with top level groups as my “pages” or “panels”.
Top Level Page: Relevant Name Panel - Group
Sub-Group: RNP_Relevant Name - Group
Sub-Element: RNP_Relevant Name - Input/Text/Uploader/Button/etc
If I have a need for further differentiation at lower levels, such as if I have two subgroups on a single page that are very similar and have many identical elements or groups in them:
Sub-Sub-Group: RNP_RN_Relevant Name - Group
Sub-Sub-Element: RNP_RN_Relevant Name - Input/Text/Uploader/Button/etc
I pretty much never go beyond having two abbreviated differentiators at the beginning, as any more than that and it gets difficult to see anything but those in the element tree. This system has made it easy for me to keep track of the thousands of groups and elements all layered into my single page native app.
3 Likes
I always make sure to keep the element type as part of the name the same way @cmarchan mentioned as it makes it a lot quicker to use one hand to type in when searching for the element for various reasons.
I personally put my custom states onto a group that acts as the ‘main-container’ of the page elements so that if I were to need to for any reason copy and past that in another area I can…sometimes I build something in one app that I end up using in another. However, this will not work if being done in a reusable element as one of the main ways to communicate from the page to a reusable element is through the reusable elements custom states.
One other thing is to keep a consistent approach (I usually don’t and it irritates me) in the structure…One of the following three is often the approach
- CapitalLettersForNewWords
2.use-all-lowercase-with-dashes (good as it is best practice in my opinion for naming pages but also avoids Bubble recognizing it as just one word and causing issues sometimes with viewing the entire name)
3.Use Capital Letters With A Space
The reason to make sure you keep that structure consistent is so that when searching for an element you know how to structure that search
Overall I make my names reflective of the portion of the page and its functionality and I match it to my workflow folder name.
One group for location-details and a workflow folder location-details so that I can quickly compare the workflows for that particular portion of a page when debugging.
1 Like