Measuring Coverage of React Design System

Hello everyone, my name is Karan, welcome all to the React Summit. Today I am going to talk about majoring coverage of Reduzon system.

To give you an introduction about myself, I am currently working as a ST2 front-end at Fabric Agency, which is a US-based e-commerce startup. I have previously worked with startups like Razorpay and Google Foods in India.

Let's have some context before defining the problem statement. I will talk about what I usually deal with at Fabric in my day to day work. We have our own dashboard, a SAS dashboard, where retailers can manage their products, inventories, customers, coupons, and subscriptions. It is a micro-front-end-based architecture. We use single-SPA, REACT, Typescript, and Style components. We were in a journey of building our design system in Typescript, which was design-system-4.0. We had our older design system, which was in Vs3. It was built using JavaScript. It was very flexible, not a design system, but a component library or UI kit. It was very flexible. So people ended up creating a lot of customization and a lot of variations of the same component in turn, which lacked consistency across our applications. So all our applications started to look like it belonged to a different platform altogether.

To resolve all the issues that we had with design-system-3.0, we decided to build our design-system-4.0 using TypeScript. It was flexible, but it had design constraints with respect to our design system. It's very consistent, it has all the support, all the latest features like tokens, spacing, color, theme, that you can use.

Let's define the problem statement where we're on the journey of migrating from design-system-3.0 to design-system-4.0. We as a platform team wanted to measure our component usage and to get some data to take data-driven decisions around our component strategies. So a few data points that we wanted to capture was design-system-3.0 usage, design-system-4.0 usage, any native HTML elements that the domain teams were using, any style components they were using built on top of native HTML elements, or any existing design-system-3.0 components. We also wanted to have a tree structure of any page or any layout so we can visualize how our different components are getting used in combination with other components. And we also wanted to highlight some anti-patterns that we can gather using the data.

So let's get started. First thing first, if you are an engineer, you get assigned any task and you try to google the hell out of it. You see if there are any existing solutions that you can use readily. But if you are a developer, you go to chatgpd type your question and hope it produces the output, but it didn't. But after struggling for a few days, asking for people help on Twitter, various platforms, I was able to find this NPM package called a React scanner. So what does React scanner? React scanner is basically a tool which statically analyzes your given code and it extracts the React component and prop usage.

So React scanner supports the following options that you can give. So basically when you run this React scanner on a given codebase, you have a few options. So first one is root directory. You can define from where your root directory is so it will start scanning from that root directory. You can also define where you want to start crawling from. You can exclude any of the files that you don't want to run a scan on. You can define the block pattern as well to include specific or exclude specific files.

You can also include sub components like if you don't want to report all the components, then you can also define using components. Similarly, for sub components as well. If you want to generate the data for only specific libraries, let's say you want to get the information from a library, like let's say what all components are using from Material.ai, then you can define your particular libraries as well. So it will generate only the data for that particular library that you've defined. Also, there are some custom functions that you can pass on. So few of them are like getComponent, getProperValue, and processors. So processors are basically functions that runs on top of raw data and it will generate consolidated information for you.

So let's talk about some of the processors that are provided by React scanner. So as the name suggests, first one is countComponents. So basically, it will give you only the count of components, like all the components that are getting used in the particular code. Next one is countComponent and props. So basically it will count component as well as the count of props as well. So here you can see text component. It was identified 17 times and in that 17 instances, the margin prop was used six times, colors four times, and text one time. So on and so forth.

So the base processor is a raw report. Basically it will generate the raw information of your report, of all the instances of text for all the components. So here you can see the text instances. It will have the information like the first object is the prop subject. Another is location. So where your particular component was identified. And it will have the prop spread information as well. If you're doing prop spread syntax, then it will give that information as well. So this is the raw report format.

So how does the rate scanner work? So basically it reads your file. And then parses your code into abstract syntax AST. Then it traverses the AST, gathers the information like component name import information. Then based on the processes that you passed in the configuration, it will generate the data and it will return the JSON. So you can write it in a separate file or you can take it as output as well. So let's talk a little bit about AST. I am no expert in AST. This was my first encounter with AST. But it's a cool tool to learn a few things about your code. So basically tree representation of your program's source code is what AST is. So I have taken a very minimal or a basic example here. You can see I have declared two variables A and B, 45, 5 and I have a function declaration which returns A plus T. So on the right hand side I have created a AST.

You can see here this has three nodes. Like we have three statements, variable declaration, couple of variable declaration and one function declaration. Here you can see. In function declaration we have block statement on this bracket and then we have a print statement and this operator and its argument too. So this is basic IST. If you want to learn more about AST, I would strongly suggest you to go to astexplorer.net and explore it. It can generate the AST for the code in any of the languages and it will give you a nice view and you can learn a thing or two about ASTs.

So let's see react-scanner in action. So using react-scanner we were able to display this information about DS3 and DS4 component usage. Here you can see in DS3 we had these many components and it's usage like tooltip, icon, model and in DS4, like grid, row, skeleton, box, icon. And in the pie chart, we are showing the status of DS3 component vs DS4 usage in this particular project called Copilot MFA admin. We still needed to figure out few things like native HTML elements, style components, component tree structure and anti-patterns. So let's see how we can do each one of them.

So first thing first, all of these like were not supported using react scanner. So we fogged the react scanner repo because it's not actively maintained anymore and it did not have all the use cases that we wanted to solve for. So we are now maintaining a copy of react scanner at Fabric. And let's start talking about HTML elements, how they differ from JSX elements. So there are two unique features or two unique differences between JSX element and HTML element is that HTML element is always lowercase and it doesn't contain any dots. So dot syntax is generally used for sub components and lower like the capitalized letters are used for JSX elements. So using this information, using this filter, we were able to show all the HTML elements that the domain teams were using and in which particular file also they were using. We were able to show that on the dashboard as you can see here in the snapshot.

So let's talk about style components. Style components is basically our cssng solution. You might have seen this syntax if you have used it before, but if not, I'll briefly talk about that as well. So you may have used this tag template literal syntax. We generally use this when defining our styles in conjunction with style components. So here you can see there are two ways you can define your style component. One is a normal dot notation, style.button where I have defined this button using that syntax, and the primary button using a function called syntax-style and in brackets I am defining this component. So let's talk about the style components using how it looks like in AST. So let's go to the first one.

You can see here in the dot notation it's getting the identifier and in the tag-template expression you can see there is a tag and there is a cos and template element. You can see here all the values that the background did and everything that we have defined here in the syntax, you can see here. And you can see where it was derived from, like what its expression name and we will be able to see it was built on top of Button. And similarly for the style-based component, you can see here that we have this call expression because we are calling the function style and in here we have the argument called BaseButton. You can see the value here, BaseButton. So we can identify using that information that the functionality button was built on top of BaseButton.

So this was the code that I wrote. So I'm gathering all the information where it was styled from using property name and the raw value as well. So after gathering the information, we were able to identify some anti-patterns, so let's talk about anti-patterns. So anti-pattern is a term that describes how you should not be performing your recurring problems. So what could be some of the anti-patterns in our use case is that using a hard-coded color instead of using a design system token or like using HTML elements, like anchor input button, instead of using it from the design system. So we wanted to highlight that in our dashboard so the teams can take corrective actions. So here is the dashboard, you can see here, we have identified a few of the anti-patterns and we have given the suggestion as well as the source of it where it arose from where the user was like following this anti-patterns. And we also, like we are also seeing the color like style component as well.

The last thing I wanted to talk about is component restructure. So we wanted to create a component restructure for any page or any component so we can visualize how our components are used alongside other components or with each other. So then usually you can see how they are arranged and how we can optimize them further or we can take any major decisions with that. So let's take a sample example. So here I have a user management form from one of the Microsoft Analytics applications. So this user management form has to components you can see one is user form and another is the user listing table. So here you can see this user form has 3 inputs and 1 dropdown and 1 button as well. And this form has like all the rows and each one of them can take action and change the role of the user. So let's talk about that. Here you can see this tree like it gives us the information this managed user space is built using buttons 3 stackbars actually button with icon this user form and this user list. So here you can see we can identify 1 anti-patron here on the first class is that we are using 3 instances of stackbar that we shouldn't be using on this page because we can do the same thing with 1 stackbar as well. Here the user form is a build using different components. So that's why it's cleared out. You can expand it further it's not edge node so you can see that user form is built of dropdown input input input and button with icon icon button actually so you can see your whole page in a single view what all components it's getting used So it's a bare bone version that I built but we are planning to add more features into it like searching for particular component and displaying them with different colours from where they belong to or where they are imported from and also the props information if we can highlight that it would be a great tool to have So in summary we were able to get the overall idea of how our design system was getting consumed. Using the data that we generated we were able to take major data driven decisions around what all props should be or make backward compatible or all props we can duplicate or what all components should be combined or what all components we should do atomically So all these kinds of decisions we were able to take using data and we were also able to highlight the anti-patterns and improve the code quality Yeah, I have a bonus for you all guys It's a tool that I have found recently which is omelet.dev which does the same thing that React scanner does but it's a all-in-one solution that you can use. It's a component analytic tool which was developed by Zeppelin So here is a simple demo of Omelet. You can see here it has the CLI tool that you can use and it has a dashboard where you can see all your data once you run your scan on. So it's much more advanced than what we have built and it supports React and React Native and it plans to add future, in future they are planning to add Angular and Vue as well. So thank you. So here are the references that you can use if you want to learn more about that and here are my socials if you want to connect. Thank you guys and thank you to the team at the Anti-Handicap Summit for giving me the chance to speak at this conference.