One Off the Slack: Design Systems and Composable Names

Bryan Herbst asked:

Why are all of the components in androidx.compose.material named as though they are the the canonical implementation, when the messaging so far is that Material is an implementation of a specific design system? Text is 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 Text
• 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 Text to something else?

Google’s Ian Lake suggested:

If you are building your own design system, wouldn’t you just also use Text in 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 Button instead of the Material button, I don’t necessarily want to stop them from using a RippleIndication from Material

On that latter point, apparently there is a plan to move RippleIndication out of material, so other design systems can use ripples.

I suggested:

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.

Read the original thread in the kotlinlang Slack workspace. Not a member? Join that Slack workspace here!