Great article and very insightful. One things that’s unclear to me is how to migrate current component naming in the way you mention.
For example, how would we avoid needing to go from a generic “button” to a context named button? It would require a specific button named component for every possible screen/page, use case, context, etc. That part isn’t tangible to be how this manifests in practice.
That's a good question! The key is using semantic props rather than multiplying components.
Button variants will probably already serve specific purposes – it's just making that explicit through props. Design tokens stay the same; you're just changing how components expose their purpose.
Kind of like HTML – we don't create new <button> elements for every use case. We use attributes to provide semantic context... The goal is encoding intent in your API, not creating infinite variations.
In saying that though, I'm also still experimenting with how that best works! It's always evolving.
Great article and very insightful. One things that’s unclear to me is how to migrate current component naming in the way you mention.
For example, how would we avoid needing to go from a generic “button” to a context named button? It would require a specific button named component for every possible screen/page, use case, context, etc. That part isn’t tangible to be how this manifests in practice.
That's a good question! The key is using semantic props rather than multiplying components.
Button variants will probably already serve specific purposes – it's just making that explicit through props. Design tokens stay the same; you're just changing how components expose their purpose.
Kind of like HTML – we don't create new <button> elements for every use case. We use attributes to provide semantic context... The goal is encoding intent in your API, not creating infinite variations.
In saying that though, I'm also still experimenting with how that best works! It's always evolving.