One Off the Slack: Design Systems and Composable Names
Bryan Herbst asked:
Why are all of the components in
androidx.compose.materialnamed as though they are the the canonical implementation, when the messaging so far is that Material is an implementation of a specific design system?
Textis a great example- it’s name alone ensures that it will be the first text Composable that most engineers reach for, but that presents two problems in my mind:
- Today, any project with its own design system has the burden of ensuring its engineers use their design system’s text instead of the innocent and generic sounding
- When a new Android-default design system inevitably comes along in the future, we have a similar problem- does the new design system create a
HoloText, create its own Composable named
Text, or does Material rename
Textto something else?
Google’s Ian Lake suggested:
If you are building your own design system, wouldn’t you just also use
Textin your own package namespace? Not including the material library (as it is a purposefully a separate artifact) would be enough to prevent confusion.
As I (Mark Murphy) noted in the thread, libraries are going to pull in
material via transitive dependencies.
And, as Bryan pointed out later:
Another challenge is that it is fairly likely that we will be pulling in Material in our design system library so that we can wrap some components that we don’t want to completely re-implement ourselves. As another example, while I want my engineers using my
Buttoninstead of the Material button, I don’t necessarily want to stop them from using a
On that latter point, apparently there is a plan to move
material, so other design systems can use ripples.
My guess is that there will be a cottage industry for Lint rules to enforce usage of the right composables.
Bryan and Alex Lockwood echoed that sentiment, with Alex pointing out this Lint rule as a possible example.
Alex also pointed out that
.idea/codeInsightSettings.xml lets you set up
an auto-complete blacklist:
<?xml version="1.0" encoding="UTF-8"?> <project version="4"> <component name="JavaProjectCodeInsightSettings"> <excluded-names> <name>androidx.compose.material.*</name> </excluded-names> </component> </project>
Jan Skrasek wondered about prefixes:
Well, if [using package namespaces] would be usable practically, Compose foundations wouldn’t have BasicText and the same the TextField should be without prefix, shouldn’t be? The reality is that including material (at least the compose’s) is a must and we and probably majority of others build upon it. Personally, this is one of my open questions if I should (re)name my components with prefix our let them just namespaced. At the same time, we know we wouldn’t wrap everything, so it seems pretty weird to have TextField and CompanyButton.
Alex and Bryan have are trying, via those auto-complete blocks and Lint rules, to go the Google approach and have un-prefixed composables.