Measuring Coverage of React Design System

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more

Design systems are becoming increasingly popular in modern front-end development. However, measuring the usage and coverage of these design systems is often challenging. In this lightning talk, I'll discuss about a tool that we're working on which uses react-scanner and Abstract Syntax Tree (AST) with custom scripts to generate component usage data for a React design system. 


The talk will cover how we generate this data and how it is rendered in a dashboard to provide valuable insights on the coverage of the design system.


- Introduction to  react-scanner

- Measuring Component Usage

- Identifying Native HTML elements and Styled Components

- Showing Tree structure of Page in terms of Components

- Highlighting Anti Patterns

- Benefits / Use Cases for this tool

This talk has been presented at React Advanced 2023, check out the latest edition of this React Conference.

Watch video on a separate page

FAQ

The purpose of the design system 4.0 at Fabric is to measure the coverage and usage of components from the previous design system (DS 3.0) compared to the new one, identify native HTML elements and style components used in applications, and detect anti-patterns in their usage to optimize the overall design system implementation.

React Scanner assists by statically analyzing code to extract details of React components, including their properties and where they are imported from. It outputs these details in various formats, aiding Fabric in assessing the usage of design system components and identifying areas for improvement.

To identify native HTML elements, Fabric reads the JSX element names, checking if they are lowercase and do not contain dots. For style components, Fabric had to develop custom scripts, as this functionality was not present in the React Scanner package, to detect style components defined using tagged template literals.

The component restructure visualization presents a tree structure of components used at a route level, allowing developers to easily identify redundant usage or potential optimizations, such as consolidating multiple instances of the same component with different properties into a single, more versatile component.

Future enhancements for the component tree structure visualization include adding property details and highlighting components from different libraries using various colors to provide clearer visual insights into the composition of pages and their components.

Fabric takes data-driven decisions to ensure backward compatibility for heavily used components, focusing on supporting these components effectively and avoiding frequent or disruptive changes that could impact the stability of applications using them.

Examples of anti-patterns in Fabric’s design system include using hardcoded color values instead of design system tokens and using basic HTML elements like anchors, inputs, or buttons directly instead of utilizing corresponding components from the design system.

Karan Kiri
Karan Kiri
11 min
23 Oct, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Karen discusses measuring the coverage of a design system using React Scanner. The tool helps analyze code and extract component details, allowing for the measurement of component usage and identification of patterns. The analysis also reveals anti-patterns in the design system consumption. By restructuring components, data-driven decisions can be made to optimize component usage at a route level and address anti-patterns.

1. Introduction to Design System Coverage Measurement

Short description:

Hi, my name is Karen. I'll be talking about measuring the coverage of a design system. Our current product is built using micro front-end architecture. We migrated from design system 3.0 to 4.0 and wanted to measure the usage of components. We found a solution with React Scanner, an NPM package that can analyze code and extract component details.

Hi, my name is Karen. I currently work at a startup called Fabric. It's a US-based eCommerce startup. I have previously worked with Razorpay and Ripple Foods in India. I have a total of six plus years of experience in front-end domain.

So today I'll be talking about measuring the coverage of a design system. To give you a little bit of context about what our current product is, so it's build using micro front-end architecture. We use singles for React, Apps Script, and style components. So, as you can see in the header part, there are different products, each is a different micro front-end and it has like different kinds of products like product management, order management, coupon management, customer management. So the product looks something like that.

So we were building a design system in TypeScript from scratch. We had our old design system DS 3.0 in JavaScript. So when we migrated to design system 4.0, which is our new design system, we wanted to measure our coverage. So the problem statement looked something like this. We wanted to measure like what are DS 3 components like what is the usage of older design system component and new design system 4.0 component usage. Native HTML elements that were getting used in our applications and any of the style components that were getting used. And last bonus point that is to like describe your page route in a tree structure using our components.

So whenever we get some problem what we generally do is Google the hell out of it. And I struggled on Google to find a solution. Then I landed on this beautiful NPM package called React Scanner. So basically React Scanner is a NPM package that can statically analyze your code and it can extract out the details of your component including its props and everything. So to go into details I have created this sample React component. Here you can see in the app component we are using some provider container and we have text and we have the link component here. So here you can see the React Scanner can generate like outputting a few different formats. One of them is raw output. So for raw output it gives like all the details of particular instance. So basis provider it will have an array of instances. So in first instance it has like import information where we are importing this component from its props and where is it in the file. And in the processed output here you can see it has like processed or like cumulative information like what are the number of instances of text component, its props, and everything you can see here. So how does React Scanner work? So React Scanner, what it does is like it reads the file and then it parses the code into AST basically abstract syntax tree.

2. Measuring Component Usage and Identifying Patterns

Short description:

It's a tree representation of your code. We were able to generate a dashboard showing the usage of DS3 and DS4 components. We identified native HTML elements and style components using a custom script. Additionally, we detected anti-patterns in the design system consumption.

It's a tree representation of your code. And then it traverses the AST and gathers the information like component name information, import information, prop information, data. Like it gathers data and then it returns it into JSON format. So using that data, we were able to generate this beautiful dashboard here you can see. We can see for this particular application Copilot MFA admin. We were using like these many DS3 components and these many DS4 components and the number of instances of each of the components we can see here as well.

So first part of our problem was solved but we still needed to figure out few points like native HTML elements style components, component structure and anti-patterns. So first thing first, what we did is like fork the React scanner repo and we are now maintaining a copy of the scanner in our code base. So identifying native HTML elements is a very simple task. So you just need to read the JSX elements name and you need to check if it's a lowercase element and it shouldn't contain any dot. If these two conditions are met then you can say that this JSX component is HTML element. So based on this conditions we were able to identify here you can see I was able to identify A tag, H1 and P tag in these files.

Next difficult part was to identify style components. So this style components was not there in the React scanner package. So we had to build on our own writing a custom script. So you can see that we can declare the style components in two separate code style. Here you can see we are using style dot button and we are using style function on top of base button. So this syntax is called tag template literals. So here is the code that we return to identify style components. So basically we wanted to identify from where this base button is built on, like is it built on top of any existing component or any HTML element. Here you can see this base button is built on top of button, but this primary button is built on top of base button. So using this script, not just the component name, but we were also able to gather the raw CSS that were written in the applications. So here you can see we are gathering style CSS raw and file path. And style from basically contains from where the style component was built on top of. And last part is anti-patterns. So anti-patterns is a term that describes like how not to solve your recurring problems. So what all anti-patterns could we have in terms of consuming design system is that like some of the examples could be like using hard-coded color instead of our design system token or like using on anchor or input or button. HTML element, instead of using it from our design system. So these are some of the anti-patterns we wanted to identify. So using all this information that we got from this scanner, we were able to like display that information in our dashboard.

3. Component Usage and Restructure

Short description:

We identified interesting stats for input and style components. We recommend using the input from the design system. The component restructure allows us to identify and optimize component usage at a route level. This information helps us make data-driven decisions and address anti-patterns using React scanner.

So here you can see that the input components was getting input as HTML elements was getting used or a style component was getting used seven phases. So we are giving the suggestion to the domain team that you should use the input from design system. Similarly for button and for the link component as well. For style components here you can see we were able to identify a few interesting stats. You can see that in this particular component, we were using the hard-coded color that we don't want to do. We want them to use the color to confirm design system. So that information we were able to gather.

So last but not the least is the component restructure. So basically to give you a more idea like how a component restructure can look, here you can see that this manage user page has been divided into multiple nodes, so each node represents a component and if it's a composite component, then it is greyed out and we can expand it further. So here you can see this user form has multiple components like drop-down, input, input, input icon button. So from this chart, you can see we can already identify one anti-pattern here. Here you can see that we are using three instances of stack bar in this particular route at the top level that we shouldn't be doing. Actually, we should be using only one stack bar with different props. So this tree structure will basically give you idea of all the components used at a route level and you can get the insights, how or what can be optimized. We plan to add many more features in this tree structure, basically adding the prop details and highlighting a different design system or a different components from different libraries using different colors so that it is visually very clear what all this page is being made of. So yeah, that's pretty much it.

So in summary, using all this information we were able to like get the overall idea of how our design system is consumed. Using this data we were able to like take data driven decisions around any major components like if the component, like how much it is used. Like if the component is used at major places we would take like, make them backward compatible and we want to support that or like we don't want to break those components very frequently or make an experimentation on the most used components or be very careful with that. And also we were able to highlight the anti patterns using React scanner. That's pretty much it. If you want to learn more about React scanner do visit this link. And yeah, if you are on Twitter or LinkedIn feel free to connect.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Design Systems: Walking the Line Between Flexibility and Consistency
React Advanced 2021React Advanced 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
The Talk discusses the balance between flexibility and consistency in design systems. It explores the API design of the ActionList component and the customization options it offers. The use of component-based APIs and composability is emphasized for flexibility and customization. The Talk also touches on the ActionMenu component and the concept of building for people. The Q&A session covers topics such as component inclusion in design systems, API complexity, and the decision between creating a custom design system or using a component library.
Build a Design System with React and Tailwind CSS
React Summit 2022React Summit 2022
27 min
Build a Design System with React and Tailwind CSS
Top Content
This Talk discusses design systems and how to build one using React and Tailwind CSS. Tailwind CSS provides utility classes for building complex layouts without writing CSS rules. Custom colors can be added to the Tailwind CSS config file, and font styles and text sizes can be customized. The entire Tailwind CSS configuration can be customized to meet specific requirements. Base styles can be added to the config file itself using a plugin. Reusable components can be created with Tailwind CSS, allowing for easy customization of size and color.
Walking the Line Between Flexibility and Consistency in Component Libraries
React Summit 2022React Summit 2022
27 min
Walking the Line Between Flexibility and Consistency in Component Libraries
This Talk discusses the comparison between Polaris and Material UI component libraries in terms of consistency and flexibility. It highlights the use of the action list pattern and the customization options available for the action list component. The Talk also emphasizes the introduction of a composite component to improve API flexibility. Additionally, it mentions the importance of finding the right balance between flexibility and consistency and the use of types to enforce specific child components.
Find Out If Your Design System Is Better Than Nothing
React Summit 2022React Summit 2022
20 min
Find Out If Your Design System Is Better Than Nothing
Building a design system without adoption is a waste of time. Grafana UI's adoption is growing consistently over time. The factors affecting design system adoption include the source mix changing, displacement of Homebrew components by Grafana UI, and the limitations of Grafana UI's current state. Measuring adoption is important to determine the success of a design system. The analysis of code through static code analysis tools is valuable in detecting and tracking component usage.
Dialog Dilemmas and Modal Mischief: A Deep Dive Into Pop-Ups
JSNation 2023JSNation 2023
10 min
Dialog Dilemmas and Modal Mischief: A Deep Dive Into Pop-Ups
The Talk discusses the use of dialogues and popovers in web development. Dialogues can be modal or non-modal and are now accessibility-supported. Popovers are versatile and can be added to any element without JavaScript. They provide suggestions, pickers, teaching UI, list boxes, and action menus. Modal and non-modal dialogues and popovers have different behaviors and dismissal methods. Browser support for these features is expanding, but there are still open questions about positioning, semantics, and other use cases.
Type-safe Styling for React Component Packages: Vanilla Extract CSS
React Advanced 2023React Advanced 2023
19 min
Type-safe Styling for React Component Packages: Vanilla Extract CSS
Watch video: Type-safe Styling for React Component Packages: Vanilla Extract CSS
Today's Talk introduces Vanilla Extract CSS, a type-safe styling method for React applications. It combines the benefits of scoped styling, zero runtime overhead, and a great developer experience. Vanilla Extract generates a static CSS file at build time, resulting in better performance. It is framework agnostic and offers a powerful toolkit, including Sprinkles for utility classes and CSS utils for calculations. With type safety and the ability to define themes and variants, Vanilla Extract makes it easy to create efficient, scalable, and maintainable design system component packages.

Workshops on related topic

Rapid UI Development in React: Harnessing Custom Component Libraries & Design Systems
React Advanced 2022React Advanced 2022
118 min
Rapid UI Development in React: Harnessing Custom Component Libraries & Design Systems
Workshop
Richard Moss
Richard Moss
In this workshop, we'll take a tour through the most effective approaches to building out scalable UI components that enhance developer productivity and happiness :-) This will involve a mix of hands-on exercises and presentations, covering the more advanced aspects of the popular styled-components library, including theming and implementing styled-system utilities via style props for rapid UI development, and culminating in how you can build up your own scalable custom component library.
We will focus on both the ideal scenario---where you work on a greenfield project---along with tactics to incrementally adopt a design system and modern approaches to styling in an existing legacy codebase with some tech debt (often the case!). By the end of the workshop, you should feel that you have an understanding of the tradeoffs between different approaches and feel confident to start implementing the options available to move towards using a design system based component library in the codebase you work on.
Prerequisites: - Familiarity with and experience working on large react codebases- A good understanding of common approaches to styling in React