build your own design system with good enough defaults that you can customize later.
Good enough... that's what I'm talking about... and 'customize later' encapsulates the escape route needed to enhance as brand stakeholders will often require, and ultimately where traditional DS efforts break down.
But there's a caveat, due to how cn is utilized it is possible for a component consumer to pass new overriding styles using the className attribute. This could open the component for modification. Therefore, when you are building your own component library with shadcn/ui decide whether you should allow that behavior or not.
This could be a good thing, and allowable in certain contexts. Marketing sites for example. Often brand wants to push a DS beyond its stated definitions, and as such, this 'abuse' of 'cn' could be considered acceptable practice in these bleeding-edge cases of marketing/brand expression
December 11, 2023
This article is a little outdated but as per my read through, the only aspect I have found that is truly 'out of date' is the way forms are implemented as that has been recently changed. The method mentioned in the article is still valid but being sunsetted as of the time I'm making this comment.
Given a design system, the responsibility of a front-end team would be to express it in code.
This comment further underscores the separation of 'DS as Doc', and puts the responsibility of code expression of said DS on the front-end team (implicitly the front-end team of a particular product)
This type of a collective design documentation for a given software is usually known as the Design System.
I find it interesting (especially given recent discussions on this topic), that the author has reduced the concept of a design system from a technical toolset or implementation to mere documentation (e.g. style guide)
These reusable components that are unstyled but encapsulate their behavior set are known as Headless UI components
Starting from so-called 'Headless UI components' seems to me a 'no-brainer' especially when tools like ShadCN is not only built on top of tech that Agentic dev tools are familiar with, ShadCN itself is also something Agents (in my experience) are well versed in.
Even though behaviors are very important to enable accessibility in our user interfaces, getting these behaviors right according to W3C specifications is a really hard task and could significantly slow down product development.
This is a key point of what slows down our DS development. While we do take care to ensure these usability concerns, and we expect reusability through adoption to spread out the cost, being able to start from a place where these concerns have already been solved for could reduce early development friction.