Measuring Coverage of React Design System

Rate this content
Bookmark

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

11 min
23 Oct, 2023

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.

Available in Español

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

React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2022React Summit 2022
27 min
Walking the Line Between Flexibility and Consistency in Component Libraries
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2022React Summit 2022
20 min
Find Out If Your Design System Is Better Than Nothing
Building a design system is not enough. Your dev team has to prefer it over one-off components and third-party libraries. Otherwise, the whole effort is a waste of time. Learn how to use static code analysis to measure if your design system wins over the internal competition and data-driven ways to improve your position.
React Advanced Conference 2023React Advanced Conference 2023
19 min
Type-safe Styling for React Component Packages: Vanilla Extract CSS
Unlock the power of type-safe styling in React component packages with Vanilla Extract CSS. Learn how to effortlessly write scalable and maintainable styles, leveraging CSS-in-Typescript. Discover the seamless integration of Vanilla Extract CSS and take your React components to the next level.
JSNation 2023JSNation 2023
10 min
Dialog Dilemmas and Modal Mischief: A Deep Dive Into Pop-Ups
Our design systems commonly feature components that show on top of other content: tooltips, date pickers, menus and teaching UI, to name just a few. Proposed updates to the web platform are about to make building these a whole lot easier. You might not even need JavaScript. In this talk, you’ll learn all about the upcoming ‘popover’ attribute, modality and the top layer.

Workshops on related topic

React Advanced Conference 2022React Advanced Conference 2022
118 min
Rapid UI Development in React: Harnessing Custom Component Libraries & Design Systems
Workshop
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