Design Systems: Embedding UI Design Patterns in React Components
Tags: react, design, webdev, javascript
Published: 2019-10-29 18:34:02

###Using React propTypes to bring design and development closer together


In recent years we have seen an explosion of tools that aim to bridge the gap between designers and developers ([Bit](https://bit.dev), [Sketch](https://www.sketch.com/), [Zeplin](https://zeplin.io/), etc.). Design systems, nowadays, are much more than a static and verbose list of guidelines — they are living systems with actual code components at their core. They are much closer to the product itself and to those who develop it.

{% post https://dev.to/jonisar/ui-component-design-system-a-developer-s-guide-19fg %}

{% medium https://medium.com/bitsrcio/building-a-consistent-ui-design-system-4481fb37470f %}

This progression towards a code-oriented design system is a real blessing, mostly since reading long lists of guidelines is an activity most of us would rather avoid. It is tedious and tiresome but worst of all, it makes it very easy to make mistakes. There is no immediate feedback correcting you if you happen to “break one of the styling rules” — you’re simply required to read the guidelines and implement them accordingly.

With today’s component design systems, “following the rules” is much easier. As a developer, you find abstract design rules embedded in your UI component library, stacked with reusable components that have been built according to your organization style guide and approved by all relevant decision-makers.

But, the story is not over yet. There are many things that are not found in the components themselves. In his blog post “[Patterns ≠ Components](https://medium.com/eightshapes-llc/patterns-components-2ce778cbe4e8)”, [Nathan Curtis](undefined) makes the distinction between patterns and components:

> **“Components are how something DOES work**, inclusive of tradeoffs and constraints realized through a build process. **Patterns describe how something SHOULD work** under preferred conditions and suggestions of how to cope with tradeoffs.

> **Components are an interface chunk** to be added to an overall layout. whereas **patterns may be UI or a variety of other things**, like a behavior, flow, application motif or something else.”

For example, your component library may have an accordion component but it does not tell you how it should or shouldn’t be used. You may use the component in a perfectly valid way, code-wise, but fail to follow best practices regarding UI/UX.

Your design team may have strongly advised against using the accordion component to present pieces of content that differ too much in length but nothing in the component itself suggests that.


<a href="https://bit.dev/"><img src="https://cdn-images-1.medium.com/max/3520/1*cSLprqDrQvzY4M9ErmsB9g.gif" alt="Reusable React accordion component in bit.dev"></a>

## Using React propTypes

Embedding components with **all** best practices and guidelines is obviously unrealistic, but there’s much more that we can do in that domain.

For example, we may use React propTypes, to implement the aforementioned guidelines regarding accordion component (propTypes can be used in development and removed from the production build using [babel-plugin-transform-react-remove-prop-types](https://www.npmjs.com/package/babel-plugin-transform-react-remove-prop-types)):

The data to be presented in the accordion component:

    const info = [
      {title: 'Title 1',
      content: 'Lorem ipsum dolor sit amet, consectetur.'},

     {title: 'Title 2',
     content: `Lorem ipsum dolor sit amet, consectetur adipiscing elit,      sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.    Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris  nisi ut aliquip ex ea commodo consequat.   Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.   Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.`}
    ]

The accordion component with propType custom validation:

{% gist https://gist.github.com/giteden/94e703fb17c76a867f593df3f79f49bd %}

The above code serves only as an example for a way in which our validations could incorporate styling rules in UI component libraries. Other validation may test for correct color combinations (e.g. color + background-color) or even component compositions (e.g. a hero component may not include a range component as a child).

![Example: [Polaris](https://polaris.shopify.com/design/colors#section-color-palette)’ color guidelines](https://cdn-images-1.medium.com/max/2000/1*uo_yu2EWmTekG1O1U98sCg.png)*Example: [Polaris](https://polaris.shopify.com/design/colors#section-color-palette)’ color guidelines*

## Conclusion

Design systems are cross-domain enterprises and as such, they should speak the right language for each stakeholder. When you want to build a design system’s style guide that speaks to developers (let’s be honest, they are not going to read your style guide and refer to it on every decision) you have to find creative ways to communicate your design’s best practices in a way developers can understand and work with.

One such example is using react propTypes to validate the implementation of your design principles in your React components. This way, developers can easily follow the desired rules without having to go overboard. Feel free to give it a try for yourself, and please comment below to share your insights.

Thanks

##Learn More

{% medium https://medium.com/bitsrcio/let-everyone-in-your-company-see-your-reusable-components-270cd3213fe9 %}


{% medium https://medium.com/bitsrcio/how-to-easily-share-react-components-between-projects-3dd42149c09 %}