Design to Code #9: The Cost of a Dot
The article discusses the author's experience in developing a design system and the challenges faced with component naming and structure. Initially, the author created a compound component API that seemed effective but later realized it was not suitable for their design system. The lesson learned was about the importance of understanding the constraints of the API being emulated.
- ▪The author initially designed a compound component API that looked appealing but was not functional for their design system.
- ▪After releasing version 0.1.0, the author deleted all components and restructured them in version 0.3.0 due to compatibility issues.
- ▪The author learned that their design system components should be universal and not limited to client-only rendering.
Opening excerpt (first ~120 words) tap to expand
try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 3863968) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } 7onic Posted on Jun 3 • Originally published at blog.7onic.design Design to Code #9: The Cost of a Dot #designsystem #react #opensource #typescript There is a screenshot somewhere in my notes from April 4th—the day v0.1.0 went up—showing a Card example with <Card.Header>, <Card.Title>, and <Card.Content> nested neatly inside <Card>. I had been staring at that JSX for a long time before I clicked publish, and what I remember thinking was: this looks like a real design system.
…
Excerpt limited to ~120 words for fair-use compliance. The full article is at DEV.to (Top).
Discussion
0 commentsMore from DEV.to (Top)
