Naming Conventions
Last updated
Was this helpful?
Last updated
Was this helpful?
When designing in Quest, itās good practice to start naming your layers, groups and frames. The names of these will export with the design itself and carry over into the code. To help the development process, it is important to make sure things are named properly and at the very least, you should try to name everything that will have dynamic content.
You want to be sure your components have the correct name so your development team knows what to do with it and find it later in both Quest and in the code, but each layer can be as important. For instance, when you add a Buy button that you got from the Design Kit, it will only be named āButton/Containedā in the layers. This can be confusing for the developer to know which button that is exactly when referencing it in code. A better name would be āBuy button, Card 1ā so they can see the intent and location of the button in the product. This may not be obvious at first because itās clear inside that component but once things start nesting and thereās multiple components and cards within a page, that name can make it 100% clearer for everyone involved in coding it.
Additionally to naming, each relevant layer a unique name is equally important. If you have several profile pictures in your design layout and you name them all āProfilePicā, Quest will export those layers with the naming convention of āProfilePic_1, ProfilePic_2, ProfilePic_3ā etc. While this technically isnāt wrong, it again is confusing as to which is which with only a number associated with it. Are they named that in vertical or horizontal order? There can be a lot of questions from the developer. A better naming convention might be āProfilePicMainā, āProfilePicSmallā and āProfilePicHiddenā. Anything that helps describe the situation better to the developer who has to add the code logic will go a long way to building the product faster. Also, for the most part it is good practice to try to avoid using non-numbers and letters as they can potentially be a problem in the code.
Natively, when adding multiple properties to a component with variants, Figma will automatically add the values to the layer name. This is helpful to see the exact use of that button and what it does. When you copy and paste that buttonās instance into your own custom component design however, it will only show it as āButtonā as that is the name of the component itself. So it is good practice to rename that component to something similar to the variantās name of the component so that itās more clear to the developer which exact button it is. And even if not using components, that clear designation helps in all cases where your design will need to have additional code.
Also make sure image assets are named properly. For instance, you donāt want your logo to be exported as āimage2ā if it is your brand logo, it is better to call it something like āOurLogoVerticalMedā to give it some better description. Also, whenever you use that same logo image elsewhere, it is good to keep that same name so there will only be one image asset instead of having multiple images that are essentially the same but end up in a folder with different names.
If you're working with a Figma file that is a mess with naming conventions, you can always use the "id" binding to give it the value you want it to be. This is ideal if you don't have access to the Figma file or your designer is just not that organized ;)
To make it easy to rename layers, you can use the Figma rename feature which lets you quickly rename multiple layers at once. Learn more about it in detail here:
And last but not least, these are just quick tips that may help your team but every team has their own way of doing things so none of these are mandatory. The more
For further reading, we recommend this article:
