In our case, we use a singular design enum file that informs a set of hierarchical react + typescript components. Some constraints that have helped us run the gambit. If you have more than two style properties, it becomes a styled-component. If you can write it without a library, do it. Use picks instead or partials when passing props to the styled components. These components leverage storybook for documentation, utilize styled-components to do away with a big stylesheet and style-collisions, and enzyme testing for a sense of confidence in their behavior and aesthetic. Names should adhere to previously established patterns and should be as clear as possible.

Component folders are PascalCased just like the components names. Each component folder should in time have an example story file, a primary component file with default export, an index file, a testing file. Props like variant and size appear over and over. These notions are not hard and fast rules in every instance, but they provide a quick and approachable pattern to refer to. Willow’s root is nested deep inside the frontend src folder, then inside that component folders and an enum file. Maybe one hard rule, don’t mess with the enums file without giving me a heads up. Like ever. We will both just end up crying if you do.

A component called FormInput has options to do currency, percentage variants of your typical text component. It has variant, size as well as states for error, success, warning and info. You want a select well then there is FormSelect. Both components are only used in forms. You want buttons, loaders, biaxial graphs, drag and drop, percentage formatting… we’ve got lots of things. You want imagery, well you can pick from SpotIllustration or Icon. You need that string formatting to match the mock’s percentage value, we have a utility for that in Willow. Just patterns over and over in a small concise folder structure.

Naming these things, that took some trial and error. No more prepending component names all with Choozle for instance. That was hilarious and short lived, because then you cannot search very effectively if everything is Choozle this or Choozle that. Important as well to differentiate between composite components and singular components. We have our own approach to Atomic structure. But it works for us. You also have to deprecate and iterate on things over time.

It is a living system, the flock of components in Willow are all snapshots from a certain time in terms of who was on the team and what did they know. It gets better and better if you tend to it. Mocks can be labeled by their literal code component counterpart. Spacing can be approximated using the system we have in the enums. Mocks do not need to be measured down to the micron with a digital ruler. There is freedom within the constraints and autonomy once you get familiar.

Leverage the patterns, be thoughtful and considerate. Over time, the good decisions add up and everything becomes faster, more reliable, and incredibly cohesive. It’s a heavy lift at the beginning, but it becomes more stable and easier to use. Even when you do break something, it’s no big deal. You learn from it, fix it, test it, version it, update the imports, communicate changes, and try again. Once again, the things I have outlined are just our approach at Choozle. Where you are at may be very different, embrace that. Find ways to optimize and establish shared understanding and buy in.