Component naming conventions

Discussion
1

What naming conventions do you use for components in Retool? Do you leave it as it comes by default, or do you rename the components?

I have just started building my first app and this is something I am still thinking about. As I use the component names in queries, I want to easily recognise the components by its name.
(I mean, at the moment it is difficult to tell the difference between textInput1 and textInput2. I assume the number of components will increase, and it will be a lot more difficult to pick the right component..)

I couldnt find silmilar topic here. If it exists, I would be happy for a link :slight_smile:

2

hey @jan_kolros !

I generally make sure I name any component that I am likely to interact erring on the side of over naming

components I won't interact with include:
text, links, dividers, statistics, etc...

components I will rename:
input fields, tables, modals, forms, etc....

I have found that this maximizes my time as a developer (not spending time naming unimportant components) while minimizing the decrease in readability for other people who will use the app

1 Like
3

I think this is a matter of preference.... I prefer to name queries and the related components according to function... get, add, find, etc..
Let's say that you have a query named getCustomers
If you add a table component to the app, I would name getCustomersTable...
Just one example...

1 Like
4

I have a pretty set way of doing it that I got from Microsoft's naming conventions starting with VB script in the early 90's when I did lots of drag/drop Windows app development very similar to Retool now. The IDE would do it for you with their standards.

Abbreviate the type to three letters (2 is ok, 4 if you must) all lower case and then camel case the rest.

Text components start with txt, so the name component is txtName. txtFirstName and txtLastName if applicable. Keep it descriptive.

  • tbl: Table
  • frm: Form
  • sel: Select
  • dt: Date
  • tm: Time
  • dt: DateTime
  • etc. Just pick one and stick with it.

I do not distinguish between Text Input and Text Area and Editable Text as they are too similar to care.

I used to make all labels lblWhatever but as @DavidD pointed out, I have gotten lazy (or smart?) and don't bother naming static components I have no reason to interact with.

Now you may have more than one select in your app for say state - one for selecting your record's state field and one for selecting a filter for your table. I always add filter to the name of that is what is is used for: selFilterState while the other one would be just selState.

Or you may have one for editing your state and one for adding a new record: I would do selEditState and selNewState

These prefixes give me hints about which properties and methods are available to me when I am interacting with my components. I know that txtName is a text field and curPrice will have a decimal number, and I should look at the selectedItem when using selProjectType rather than value when I use txtProjectType

For my queries I use these prefixes and then describe what it does:

  • qry: SQL queries. I also add the table and action to the query name: qryCustomersSelect and qryCustomersBulkUpdate. If a query is a SQL JSON query that filters one of the others I append _filtered: qryCustomersSelect_filtered. sql seems like a better choice but I made my bed and am sleeping in it.
  • js: Javascript queries (jsExpandRowToggle)
  • rest: REST queries (restSTAddEvent)
  • tr: Tranformers (trDuration)

If a query if performing a specific function, like behaving as an event I prefix it with on what it is acting on and the action like onJobLinkClick.

I treat my Temp State vars like global variables and just give them a descriptive name. I should probably prefix them with ts or g or something to indicate their nature, but I have not so far.

I think that is a pretty thorough overview of my naming convention guidelines. It may be old school but seems appropriate to the platform.

5 Likes
5

Thank you guys for sharing that with me!
Especially @bradlymathews for very very thorough answer, that is what I was looking for. I will try to apply it to my app.