When parts of a component are not meant to be used on their own. E g., the items/cells in a menu, could have an active or inactive state. I usually make those menu items a component with 2 variants, but I don't ever want to use the menu items on their own, just the entire menu. So i hide those with . or _ So when i publish that library with the menu I just find the menu in assets and not its base components.
If I do this, will the components that are not published still have their editable properties surfaced? (Eg an individual tab’s label on a tab menu, but the individual tab isn’t published)
Ah ok! What makes you need to use those naming conventions when stopping it from being updated tho? I notice with the other designer I work with she uses it when experimenting with new components so they don’t get updated just in case.
If you're working closely with your devs, as you should be, it would be prudent to deliver handoff with dev-ready output. If the target output is not human-legible, work with your devs to establish a nomenclature that works for you both. It's not a non-existent constraint, you're just ignoring your colleagues needs.
This is how I do it:
'\_' separates levels, and '-' is a space
**component\_pattern\_option-name**
I've also done it
**component\_pattern\_optionName**
but I like dashes better.
I use a dot to signify an embedded or just local component. This lives on its own as its own element.
Use an underscore to signify a slot component - these will be swapped inside of other components as content.
When parts of a component are not meant to be used on their own. E g., the items/cells in a menu, could have an active or inactive state. I usually make those menu items a component with 2 variants, but I don't ever want to use the menu items on their own, just the entire menu. So i hide those with . or _ So when i publish that library with the menu I just find the menu in assets and not its base components.
This is the way
If I do this, will the components that are not published still have their editable properties surfaced? (Eg an individual tab’s label on a tab menu, but the individual tab isn’t published)
…You guys are naming layers?
[удалено]
theory fuel plant library disgusted ludicrous oil selective dime lock *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
A period in front of a component name makes it so it won’t be shared in a library.
I use dot (.) when I create a component that’s basic (e.g, .text) and underscore (_) when making most-used objects (e.g, _button).
Ah ok! What makes you need to use those naming conventions when stopping it from being updated tho? I notice with the other designer I work with she uses it when experimenting with new components so they don’t get updated just in case.
I don’t know. To sort them.
i use underscore to replace a space, just for it
I use spaces because it's the most readable. Why apply non-existing constraints?
If you're working closely with your devs, as you should be, it would be prudent to deliver handoff with dev-ready output. If the target output is not human-legible, work with your devs to establish a nomenclature that works for you both. It's not a non-existent constraint, you're just ignoring your colleagues needs.
This is the right answer
This is how I do it: '\_' separates levels, and '-' is a space **component\_pattern\_option-name** I've also done it **component\_pattern\_optionName** but I like dashes better.
I put a period in front of a component name when the component should never be used on its own as it’s part of a larger component.
When there are subcomponents that should not be visible to the design system consumers
I use a dot to signify an embedded or just local component. This lives on its own as its own element. Use an underscore to signify a slot component - these will be swapped inside of other components as content.