Node Congress

Node Congress 2022

Towards a Standard Library for JavaScript Runtimes

James Snell

React Advanced

React Advanced Conference 2021

Design Systems: Walking the Line Between Flexibility and Consistency

Siddharth Kshetrapal

React Advanced Conference 2022

My Accessibility Journey: the Quest for an Accessible Component Library

Hi, the first time I had an accessibility test a few years ago. It was a success on one end, but the complete failure on the other one. We had an application and we worked very hard to make it accessible applying many patches and specific accessibility techniques and accessible code. But every time where to change something in the code, for example, a branding effort a new colors or a new interaction. Accessibility will just left behind because no one remembered to test it and for that it was most of the time it was broken a lot like this. I mean the s*** the code. worked functionality wise but if you look under the hood it was full of patches full of hacks not something were very proud of And it was not something that you can maintain for a long while. So that's why. In my other project when we started a new accessibility project and in a different company. We did things in a different way. We wanted to make it accessible from the start and in the maintainable way. and if you're tackling the same problem today or your Trying to make your application accessible in the way that we left. This talk is free. So let me start this talk is called my accessibility Journey the Quest for an accessible component library or as should full name be. Makes accessibility generally the Quest for accessible component library that likes prefactors and redesigns and is maintainable and testable which are like small points, but they are very important for us to have accessible code. So let me introduce myself. I'm a staff. I'm the father of star etan and Aviv, Mary tunetta. I've been doing the web development field for over a decade in very small and currently I'm the front and tech lead for events, which is a startup that's specializes and giving developer great developer tools for accessibility. For example, we have algorithms baked based on computer vision, and she learning that helped detect and find accessibility issues. We create Chrome extension and other extensions for mobile as well it help developers and testers to find their issues on their application and We develop sdks that expand testing Frameworks such as Cypress or selenium and give them accessibility add-ons for their testing and I'm going to dig into the last one in short while in this presentation. so Let's start before we start what is accessibility? Accessibility is about inclusion is about letting everybody in letting letting all the people use your amazing application. for example a person who have a physical disability and cannot use the mouse will still need a way to navigate through your website and to click on your drop down and to select the third option that opened another Sub menu and then to select the fourth option from there. So if you have some kind of navigation or some kind of interactions for the users that we all have in our applications. You make sure that this is also accessible for someone who cannot use the mouse. And it's not trivial. It should be but it's not. so what we do is we want to prevent this kind of things from Lefty from from living. Our code I mean we want to ship only code it is accessible from the start. So when we want to make our own application accessible without where can we where should we start doing this effort? So we had several ideas? It all came from the testing from the testing side of things. I mean, these ideas are very much like discussions we had about testing so we can test the product or test accessibility of product flow by flow. For example, we can cover the login flow start with again screen and confirm. The login pop-up is valid the forgot my password flow works and sign up and sign out also works with the keyboard and with screen reader, which is an accessible technology. For example The same for purchase flow and same for the contact support flow. So sorry for my voice. I have a bit of cold. Thank you for completing it in your head. So another option is to go Page by page. If we go pageway page, for example, let's cover the entire accessibility aspect of the homepage. Let's make sure that every image in the homepage has an alternative text. Everybody button can be accessible by keyboard. Every form has a label that's a screen reader can tell the person who is looking at the website. What what the label is But there's a third way that comes more naturally for us. as developers and this is my thinking about components. Because as what the front and developers we tend to think about the world herbal applications as build out of components. For example, my website is built out of buttons forms pop-ups labels input Fields, maybe drop menus select boxes check boxes, and we are doing composition like we're taking this component in that component and we assemble forms or assemble graphs or assembled Pages. Let's have a big table and the menu and some text field. and accessibility company we wanted to make sure that Our own application is accessible. And we decided to start. From the component level. I mean flows are evalued way also pages. but components we love and this is the recipe that works for us on creating our own accessible component Library. So the first step is to break down the application into small components in our case. We had four applications and we need to identify the common components. And maybe change the API so it will be so it will be the same for all of them for to match all of the use cases and then we put them in a separate git repository, but it's first it starts by identifying which components are. Are in common for all the projects? Second we focus on the components one by one and we try to build them as accessible as possible using the appropriate HTML tags. I'll dive into that in a minute. And third we automate the hell out of it. We had automating. We're automating functional tests and accessibility tests. Let's dive into it. So the first part is to break it down into small components. Let's take this imaginary application. For example. Imagine. It's like a website. You can book a Harry Potter character and it will come to you will come to your house or to place that you want and we'll pay your visit for small. It's a great website. If you find the real one, please let me know. I'll use it for sure from my daughter's birthday. So let's Identify some of the components here. Here, I mean there is a drop down that you can select the character. There is also drop down here that you can select the location and there is a date speaker. It is now marked in pink. You can select the date that the character will come and there is a search button, which is a button. And this button for example can have an enabled State disabled state. It has an hover State like when you hover over it and when you focus it with the keyboard, maybe tell some kind of tools it maybe the tooltip has a specific design or a specific appearance in specific cases same for the drop down for the same for the for the date picker. It can be a pretty complex component. now after we identified these components there are separating them from our repositories from our product reported stories to a common repository that with his sole purpose is to be a designated repository for these components In our case, we call it the common component repository not very unique but pretty straightforward, which is good naming. And after what we consume this by all the products and this component has different size building blocks. It could have a small button or input field. It can have an entire table that has filters and has an ability to talk to the server or to work locally and you have sorting mechanism and you have some kind of error handling inside of it. I mean, it could be pretty complex component as well. And because we went with this approach, we also decided to focus on functional and accessibility tests for these components. The stack that worked for us and is also suitable for this conference is react and typescript. For building the components and we use storybook. to to visualize the component and also the basis for our tests which are you in a little while? And we use Cypress for tests. Enter KCI for continuous deployment. Okay, so the second part. Now we want to create. Now we want to create an accessible component. So let's make an accessible button. Let's create accessible button. What does this mean for a button to be accessible? Just think about it? Well some of the characteristics that make a pattern accessible is that if you cannot use a mouse like we said before you should be able to to focus on that. But then using your keyboard and after the button is in Focus imagine you have like five buttons in a row, you need to give an indication of which of the button is in focus and then after the focus on it, you need to support the enter key or spacebar key as an alternative for click and the last thing we want to hint assistive technology that the element is button. So it will know it will tell screen readers or other assistive tools that this is the button Okay. Now when we have this these demands in mind, let's go into the code. So this is the basic start for a button. It's a div it has some class and ID so we can use it for styling. It has an on click that opens an alert and it says I'm a button. Now, let's make it focusable with keyboard. to do it We'll use the Tap index attribute the tab index attribute tells the browser that this element is on the tabbing list. So when the user clicks the Tab Key he will or she will eventually focus on this element. Now we want to make sure that the enter key works, so. There is not really an easy way to do it. But to add an event listener that listens to keep us. And now we need to filter these key process to see. Okay. So if it's an enter, we need to trigger the function. If it's not enter we should do nothing. Maybe if it's a space bar. We should also trigger. It depends on the operating system. I'm not sure. But some things you need to be done there as well. and now we want to tell screen readers that this element is a button. So we will use the role attribute. Okay. So what we have here is a working button, but it's merely the start of a button because our button will need to have enabled stay disabled State primary mode secondary mode, maybe a mode for button with images. Maybe you should have like specific state for specific pages. I mean the code will only increase from from here and this code actually doesn't even cover all the accessibility aspects in a lot of code. What if I tell you there is a different way and E31. what if We will just use HTML button tag. so what will happen if we use the HTML button Tech we will get all of these things for free because HTML. Has some great accessibility features baked inside of it. So we will get keyboard focus with some indication you can style it if you want and we'll get the onkeepers and we get the roll for free and we don't need to worry about it. So the first thing we learned from building our own accessible component library is That we need to love HTML tags and not just throw divs for everything. It will save a lot of time in testing and we just give A features for free this is true for buttons, but it's also true for impulse fields for labels for headings. for other attributes Okay, and let's talk about adding a level of automation. So you add the accessibility component testing automated testing? First let's create a component. So this is a component. It's a button we learned from the previous slide that the button has to have the button tag. So we use the button tag. It has I think that's interesting. Here is the primary prop. We said that is it a primary or secondary, but now we set this button and we create two storybook stories. The primary story and the secondary story if you're not familiar with storybook, it doesn't really matter. It's a great tool but it's not the subject of this of this talk, but go try it. It's really great. So if you run storybook we'll get actually we get two screens that render only the buttons and it looks like this. It has the primary button that looks like this and the secondary button that looks like that a bit different colors. Now we will use this as a basis for our tests. In storybook, there is a magic button. I put a bunch of arrows. So we want to miss it. If you click it. It opened the component in a separate tab, actually without all the wrapping of storybook UI so it will open without the toolbars and it will isolate only the component we want in a specific state with specific props. We will use that as a base for our function and explain it testing. So this is our functional test. We use Cyprus for it. And test is pretty simple. We see two tests which are identical first for primary button a second for the secondary button. They visit the URL that storybook storybook created. We click on the button and we assert that the click is registered and if we want to run it with Cypress. We see that everything works and it's great. It's green again. Okay, now let's add accessibility to the mix. So what should we expect from an accessibility framework to fine? Some of the things that we wanted to to tell us. is that there is a missing alternative text on an image or we have a button but it's not focusable by keyboard or we have a pop-up, but the pop-up is not accessible or we have text in some color and with some background color, but It's not the color contrast is insufficient. So it's hard to see for people with low visibility all of the things and more are the things that we are working on in events. These are kind of the things that we are detecting using our engines. so because we were convinced we want to use our own tools. So we use our own tools also for test Automation and we do we do it by providing an SDK for Cypress. That gives us the ability to gather accessibility issues. So if we call Ivy start this is the command it says events, please start Gathering accessibility issues. And then we do something and we call Ivy stop and then it gathers all the issues and we can run our validations against this issues run the expect or assertions in our test. So this is how it looks. The middle part of the test you can identify it from before. This is the same test the functional test now before when the functional test because if you start so it will start gather accessibility issues and after the click is done. We expect that there are no accessibility issues at all. So let's give it a try. Okay, now we run it and we see that. Things are not going very well. I mean there is a bug so Let's look at the report and we see that there is a color contrast issue. And the image hints that it related and the selector that iterated to the corners between the text color and the background color to be more specific. There is a contradiction a bad contrast between RGB 1004 1006. Oh nine and white well, because I'm not a qualified and I designer. Sorry. I'll do what any good developer would do and we said let's replace it with black and it works. Now the color contest is great in real life. I would consult a designer, but please talk and I'm alone here. So and now this is for a single component. And we do this for all of our components and this process happens during our pipeline. So every time we push new code we start storybook. We run all accessibility tests and our functional test and if everything goes well, we deploy a new version of the component library to be consumed in other products. So this is how it looks in real life. Sorry. so our component Library consists of more than 100 and well the 140 components wanted 170 stories and tests. Each story is covered with both functional and accessibility tests. It used across four projects where team of six people almost seven people. depends that you count and this library and this approach saved us saved our accessibility during a huge rebranding effort. We just did so we change basically both the components were changed by the accessibility level was kept High because we have the test harness to keep us accessible at all times. So before we end. Takeaways if you want to do the same or if you want to take advantage of the same approach. first divide and conquer split your code into small components. Be friends with HTML get you know, your html text and automate as much as you can automatic accessibility automate your deployment pipeline. It will save you lots of time. So To sum it up accessibility is not something taught in the academy or in boot camps. And it's a shame because it makes developers feel inconvenient with it at first but it's so important. So my advice to you is don't overthink it you don't have to must have a PhD in accessibility to start your accessibility effort. You can take you can take it one component at a time just start, so I want to thank you for listening. It was a great time talking. talking here in the conference and I will be available available in the Q&A session in short while and feel free to contact me on LinkedIn or via my blog and If you hesitate just remember that accessibility is much more accessible than you think. Thank you very much. I would love.

Asaf Shochet Avida

Developing and Driving Adoption of Component Libraries

Hi there. I'm Lachlan and today with my colleague Logan will be talking to you about developing and driving adoption of component libraries. This will be broken up into two parts first. I'll be speaking about what makes a good component API. And second Logan will be talking about talbi measure the success of our own component library and how we use data to inform us of how we can better improve it for our users. Quick introduction. I'm a tech lead at tiktok working on Design Systems and maintainer of our internal component Library called tux. So I spend a lot of time thinking about component libraries and how our users interact with them. So first, I'll ask what makes a good component library and from my point of view. The API is easily the most important thing the way that developers interact with the library. So what makes a good component API? So I found that apis sit along a spectrum ranging from rigid to flexible. If you imagine a UI component for example a date pickup. If we gave it a rigid API, there are some advantages to this. One is that if it's rigid and there are very few ways in which you can use it. It generally is very easy to use because there are very few ways in which it can be misused. Secondly, it has consistent outputs. Meaning if multiple teams using this components. It's very likely that they're using it in the same way and you'll get the same look and feel across the different products. Thirdly and somewhat selfishly it is a lot easier to implement a library that has a rigid API compared to one that is truly generic. On The Other Extreme you could build a date picker in a very flexible way. And that would cover more use cases. This is also really important because if a component doesn't fit it uses needs. They might have to build their own or get one from open source. And as soon as they do that, you're potentially sacrificing the consistent look and feel that you're trying to achieve through having a rigid API. So our approach is we've recognized you don't need to and can't really cover a hundred percent of use cases. So instead we aim for the common 90% and try to make the remaining 10% easy for teen Studio themselves. So therefore we start neither left of the spectrum with a really rigid API that focuses on solving the hard problems for example accessibility features and animation. I call these problems hide because most Runner developers don't have experience solving these problems. And would rather spend their time working on things like application logic. We move further right along. The trim as necessary if we're presented with a really good use case that we can't support with our current API. We'll consider opening up the API someone. But this can evolve breaking changes which Logan will talk about later. We also need to be careful because moving right means we are potentially reducing consistency and increasing complexity of the library itself. I'd like to give a demo showing how we can take a very simple component with a very rigid API and gradually make it more configurable without making too many sacrifices to as easy views and to providing a consistent look and feel. So here on the right hand side, we have a demo component, which is a drop down listbox, which I'm sure you've all seen before. And let's have a look at the API. So as you can see on the left hand side, here are the props that this box V1 takes. And importantly it takes something called items which as you can see up here is an array of what we call list items. And they can take label and a value and optionally be disabled. So as you can see, this is pretty easy to use but you can't really configure anything about it, especially how it looks. And imagine we have a product team who have this flavor picker. And they maybe want to explain to the user why certain item is disabled. Maybe this item is sold out and they want to convey that to the user somehow instead of just disabling it or hiding it. So let's move on to a V2 of our component. This is one way of addressing the problem. Okay. So as you can see here, the props are pretty much exactly the same as we won but the items. Additionally take an optional tag prop which can pretty much convey. Whatever you need. So as you can see on the right, we can now Mark an item as sold out. Maybe Market item is new. And this is really nice. But what if the team needs one item to have more than one tag not it could be new and also sold out or not. It could be popular and new. Um, or maybe what we want to change the color of these tags, so they're more identifiable. For example, green signify some kind of positive connotation maybe used for new items while read could be negative is for sold out items. So, of course we could make this more complicated this type so you could configure everything about the tags and you can provide more than one. But this is really just a service the needs of one product team and if there are 10 or more product teams all with different requirements. This is going to get really complicated maybe kind of hard to use. So maybe there's a better way to do this. So let's move on to version 3 about component. And this uses an API that we use a lot internally a tiktok and our libraries. So version 3 of our list box, it still takes the same items array, but it now importantly takes two additional properties render button and render item. You might recognize this pattern as render props and we find a really useful. So here let's configure how the bottom gets rendered. And this is basically the most simple way of using the component. But the cool thing about this is the items. Are a generic type so you can add pretty much any data to these items and then use it inside the render method to get really configurable like list items. So I'm going to copy an example I made earlier. To show you what I mean. Okay. so you can see here. As well as the labeling value we've now added the additional properties is new and is sold out. And render methods not only shows the label that also checks if the item is new or if the item is sold out and conditionally shows a tag. This tag is actually another component in our component Library. So it's kind of cool that we are composing already existing components with this listbox. So maybe we can get a more consistent look and feel across each of our components. So let's have a look what it looks like. Great. So this is pretty neat and again because this is a generic type protein if you just add more properties as they need so maybe we have is popular. On what it is? Maybe the banana is popular. cool and maybe if it's popular we could add a popular tag. And you can see the type difference is great because it's generic type. So it's really handy. Okay. Yeah, we have a popular item. Very cool. I'll show another example maybe a product team needs to have a list box of employees and they did only tags really bit. Maybe they need something like an avatar picture to show what the employee looks like. Maybe even on online offline indicator. So let me bring up an example that I made earlier. see again Now items basically have now an avatar and an ease online status. and the render method if we look at render item. We also optionally adding an avatar. And again, this is a component for our component Library where we're using. So it's really nice. We're able to compost things in this way. So if you have a look on the right. We can Mark employees is online. And we can even display them inside the Picker button. As you can see up here. So this is an example of how we design our apis to try to strike a balance between ease of use consistency as well as allowing for some configurability. I'll now headed over to Logan. Hey everyone, I'm Logan Rolston software engineer at tiktok and I will be giving the second part of this talk today. So Lachlan already talked to you about what factors and balance is. We need to consider in order to design a good component library, and I'm going to continue by tackling the Salient follow-up question. How does one go about quantifying metrics to measure the effectiveness of their component Library? We'll go over how to collect these metrics on how your component library is being used in practice and then talk about how we use this data to drive our decision making and evolve our component API said to talk So brief intro about me. I'm Logan. I work on the tux component Library, which is tiktoks internal UI. Come on a library. And some of my work is on the infrastructure surrounding Design Systems. So static code analysis tools that we'll talk about in a second linking code mod kind of stuff. So let's let's start with how to measure a component library's Effectiveness. So when Lachlan talked about what makes a component Library good he reference a couple kind of abstract quantities, like flexibility and rigidity that we can that we can describe a component library in terms of these also like brand Unity developer productivity and an increased to code quality. These are all things that we want to find just the optimize we want to have high developer project activity high quality obviously, but they're hard the measure and practice because they can be they can be quite abstract. So when it comes to finding heuristic we can we can use the represent these the one of the primary ones that we use is adoption rate. So adoption rates really important measures how much an engineer actually wants to use your components because let's say your components aren't flexible enough. So take take let's say you have a text input and it doesn't have an invalid text state. For example, let's say they entered a password with too few characters or some form data is incorrect or an email is not in the right format or something like that. You want like a red border around it and an error message below it. Let's say you don't have that. Then the developer is gonna have to go build their own component which is gonna be a huge waste of developer time. And there's also going to lower your adoption rate in similarly. If your component library is not rigid enough. It's way too complicated. There's way too many options is the developers. So just getting lost in some LA's of various configurations, then they're not actually in the user component and you're adoption rates go down. So adoption rate is a primary heuristic because we know that goes up we're doing something right. So there's this actually a variety of ways to measure adopter mate too. But one of the primary ones we use is component coverage. So component coverage is just the the ratio of the number of times somebody is using one of your components to the number of times. They should be using the your components. So we call the the times that they're actually using a components good cases. So we're going to take talks button our button component for example here. So just every time they use the jsx element text button and a file that that's a good case and they're doing something right they use in the right component and then every time they're using something like my own button or an anchor tag with the class name a BTN primary that's probably gonna be a bad day. So that's something that they should be using tucks button instead for and then let's say that in a given a source code file. They they use text button three times and they use a combination of my own button and an anchor tag with class name of B. Primary nine times. So then we're going to say that in this file tucks button has a component coverage of 25% because it's three good cases over 12 total cases. So three over 12 25 percent. Now one thing the note here is well, it's possible that accurately determine the number of good cases. I'm completely is the bad cases is actually a text inference problem. So the logic there is a little fuzzy. So so it's hard you can never guarantee bad cases calculated perfectly, but that said it's still it can serve as a very accurate heuristic. Okay, but that's not the only metrics we're limited to we can collect a bunch more metrics. For example. Another one for adoption rate is we can do adoption rate at the replay level. So we look at all the code bases that we have internally we say which ones are using tucks. And which ones I should be using talks and we can calculate coverage ratio for that too. We can look at the version distribution which ones are stuck behind on old versions of talks and not actually using the most update they can components. That's something of Interest. We can look at the styling standards adoption rate. So for example, if we're using Tailwind Atomic CSS classes How often are people actually using those atomic CSS classes versus styles that are exactly equivalent and should be replaced with that Atomic CSS class. So we know Force some semblance of code style or brand Unity or whatever Constructor here. We can look at the the rate of bug fixes or feature requests over time. We can look at linting rule of violations that are related to the component library and there's many more metrics. They're useful to correct. So how do we actually collect this data? So the primary way we do this is we through a tool called Tech scan it so text scanner is a static code analysis tool that goes in and looks at our individual files of source code without executing them and measures how fast is being used in practice and sends a state all off to an API so we can go and analyze how the text is being used. So we start here. We have a file source code we go and we parse into ST which is just a tree representation of the source code and then we go and we evaluate a set of metrics on that AST and those will give us scores so it could be like 80% component coverage before or maybe there is 12 deprecated components being used or something along the lines of that. It will just collect us a bunch of scores. We'll conglomerate them all together and send it off to the API so that we can look at how all our code files are using tux and filter over time by platform by the metric and whatnot. So the do a little bit of a deeper dive into how scanner works. So we start by parsing the source code files into asts app sax syntax truths, which is just a tree representation of the source code. It shows how all the constructs of the language are related so would so like the jsx elements related to the class name attribute and have a tree based on that. And that's just allows us to go through and evaluate a set of metrics on there. So metric is just a function that takes in a set of asts it goes in and traverses those asd's and produces a set of scores and a score is just the number of good cases the things we're doing right the number of bad cases the things we're doing wrong and need to improve the improve our score the call sites of the good in bad cases, which are just the links to the the nodes usually a suggest X elements, but you'll be like say like an input direct relation or something just a place in the code where something's going wrong and then the coverage force and then we go conglomerate that all together. We send it off to the API so we can filter by time and by package and whatnot. Okay. So now that Tech scanner and it has collected all this data, how do we utilize it? So at tiktok's things grow quickly and our component library is no exception. We need to be able to evolve fast in order to keep up with the dramatic rate of change and we want to be able to do that in order the stay Nimble and keep on evolving. So we need to be able to keep us working and throw out and redo. What is it now? This is a good truism for for how coach is best meme maintained but it's not often practice and that's because introducing all these breaking changes all the time isn't Fun for developers to keep up with it makes your life. It makes your life hard and introduces a lot of Maintenance but we can't we can't look at these things as for the lens of being a maintenance burden. We need the always be striving the introduce in Breaking changes in order to go and reach for that asymptotic platonic form of what a component Library should be and we can't we Abandon that for the sake of stability. We've got it. We got to stay nimble. So we cannot be afraid of introducing breaking changes to components. In fact, we want to be making them regularly. But we've got to embrace the breaking changes. So this is easy to say in theory, but it's hard the the doing practice and it tiktok. We've made a concentrated effort to streamline our architect for the facilitate this so once such example is we use a mono repo and in a mono repo almost all I ever consumers are on the latest version of talks and this means consumers aren't left behind because let's say we introduce a bunch of breaking changes and release like version 5 or whatever it talks but a lot consumeries are on version 3 because they want to have to go through an update to all the new the new changes. This means that we're not actually practicing what we're preaching because if people aren't actually using your new latest Cutting Edge components then practice they're just all being left behind and this guy behind us. So this means that whenever we reduce what introduce pricing change as part of that we've got to go and update the majority of our consumers to To use the latest version of talks because the majority of our consumers are always on the latest version of tux. And then this means an important philosophy that we have to enforce. This is the white of con ownership. So at talks if we make a breaking change to our package, it's our responsibility to update our consumers not the consumers responsibility. So we have to go through an update all the call call sites for code mods or whatnot and make sure they are on The Cutting Edge. Okay, so quick summary we talked about what makes a component Library good we talked about how to quantify a component libraries Effectiveness and we talked about how they use that data to evolve your library. Thank you very much. I appreciate it.

Logan Ralston

Lachlan Bradford

React Summit

React Summit 2022

Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components

 Hey today, I'm going to talk about how to build flexible resilient and future-proof components in react. I'm going to cover two different approaches to building components composition and configuration. But first, let me tell you a bit about myself. My name is Thomas Finley and I'm a full stack weapon mobile developer with 10 years of programming experience. I co-owner of Hindi webtech as well as a mentor and consultant at good Mentor IO platform. Besides that I'm the author of react drone Enterprise and view the road to Enterprise books. I also write articles for taleric and the auto Enterprise blocks. Okay. That's enough about myself now. Components so let's be honest building future proof components is not easy. I mean well if you haven't component like this, right, it's very simple. So for this example, I will use an alert component. So for example, if you would want to have an Allied component that would display this key pallet message, but we could do something like this, right we could receive text intrusion as props. Have some this was difficult styles. And then render what was passed right and here's how we could use it. Just use the light component and pass the text message inside of it. So obviously that's very simple. But the problem with building good components is that as we need to add more functionality the complexity just Grows Right and the code is becoming much harder to maintain and extent. So what if we would want to add more features to this alert component? Let's say we want to add a header as well. So we could receive a header as a prop. And if one was passed we would display it, right. As shown here in the example. So for instance on the right side, we have one alert just with the text message and the other one with both the outlet header and the text message. So that's quite simple Style. Now what about variance? Well, I guess we could again add another prop like variant, right? And then based on that prop and whatever the variant was selected we could add a prepaid Styles. So for instance, we could support the Vans like success danger warning or info as you can see on the right side. And that's how it that's how we would use it. We'll just pass header and variant probes and some text inside. Okay. So what about adding maybe an icon? Well again another prop. icon if it was passed. And we found a supported icon then we can render it. Simple, isn't it? And that's why we could use it. So basically by default the icon could be displayed on the left side. But what if you would want to actually be able to specify on which side we wanted to display the icon like maybe not on the left but on the right? Well, guess what? another prop So for instance, we could pass a problem like icon position right by default we could set it to left. And then if for instance it was right, we could specify some class right? That'll be added on the alert container. Note that I'm using Talent here for classes. And yeah, that's how we would use it just more props. So That was the configuration approach. Right? Basically whenever we just need to add more functionality, we have more props, but well that can be problematic at some point because the thing is But before every new variant and functionality, we need to add more and more props and conditional logic, right? And sometimes it might just become much harder to like, you know, overwrite the already defined logic inside of the component or even extended. So that's not really the best the configuration approach makes it much harder. So and sometimes even component can be extended. We might need to build a new version of it. Well as for pros, well, obviously a configuration approach. Well a component built with a configuration approach is quick and easy to use right because you only need to know about what props are really available and what you need to provide. And so yeah, basically different functionality in visual events can be controlled by props and that's it. And another benefit of that is that it's much harder to diverge from the design system, right? Because the thing is you only can provide props in that set. You can do read anything else with it. So well this keeps the UI in Behavior consistent. but yeah, like I mentioned the problem is that we can't easily extend configuration. Build components or override it. So what can we do? Well, I mean we could obviously Provide maybe props. Like let's say you render icon render header, you know render body and so on and so on but again more props, it will be just more messy. So be more conditional logic inside of the Allied component. So instead of trying to configure everything. How about We'll use a different approach composition. So in this example, we have one free components first the art wrapper then alet content and Allied body and to the other body. We pass the text message. I know three components just for the text message isn't much but stay with me. So how it could look like basically the alert components obviously do the receive some probes. Then it would render a diff with a puppet Styles and children, right? So in this case, the children will be the alert content and alert body. Then we have the other content as we see it's very similar to the alert component because again, you just receives the props. And has a diff with some styles. And actually well the same will apply to other body. I know there's a bit of repetition and we have a few components already, but it's worth it at the end. Just remember that it's a contract example. So yeah, that's how it that's how we use it. Now if we would want to add let's say an alert header. Well, we don't need other prop. We just add another component like alert header basically, so all these components are just building blocks which we use to compose the functionality. And what about Let's see. So first up again as Heather in this case also is very similar to other components. You just receive the props renders the diff with correct styles. And then finally the children. Now next what if we would want to have variance? Well, I guess maybe we could actually pass that one prop to download component. Of course, we could also create a component for it. But for this example, this will do. So with passive variant probe to the alert. But now the thing is that we can't compose the components right to build the alert functionality. But the thing is that we can also use a not only the building blocks the components that we build specifical for the alert, but we can actually just use any custom markup we want. If we really wanted it, we could not use any of this building blocks just the alert component. So how do we provide a variant tool? No, all these other components like Iris header and Allied body because they need to know what's the variant? Because they need to have appropriate Styles like for instance the header and body for the success variant have a dark green text while the background for the alert is light. And also we have the border on the left that is dark. So what we can do is we use context context API to basically provide the variant that was specified to all the components in the component tree So in this case, we receive variant as a prop. And then we pass it to the variant context provider, right? And besides that we also use it to specify a perfect classes. for the alert component now, let's have a look how we can build this variant context provider. So I've used a little context actually helper. We'll get to it in a moment. Basically. It just returns a custom hook that will consume the context and the context itself. And as you can see on my five here, they use variant context is exported so that it can be consumed in other components. And then in the variant context provider, we basically just render the provider and pass the variance to it. That's it. Next and so here we have the context Factory. Basically, it creates the context create the consumer and return them. Now Alice header. Yes, so we need to know update the alert header and other body components because they now also need access to the variant. So we import this variant context hook we consume the context. And then we use it to apply a prepaid styles. And we do the same in the alert body again consume the context. And apply the styles. Okay. Next so we have alert components with variance in icons, right? So if we wanted to add an icon again another building block, right we can just use a component. That was already built as part of the let's say no all the alert components and pass the specific icon or if you would want we could even add some custom markup for it. Now how would we use it? so first we can have a icon config map. We're basically the icon is mapped to let's say sfg icons or whatever the component you would want to use. Next we use the icon prop to retrieve one of the icons that are supported. and if we have one then we render the Market Besides that we also consume the variant context. So we can alter prepared slice to the icon. For example, correct colors. Like in our example the success icon obviously will be green while warning icon will be orange. So as per positions, well, basically we could move the alert icon component to the bottom and we could add some styles to it, right? So for example in this case the alert icon because it was moved to the bottom. You will be rendered after the alert content. So it would be on the right side. And then we for instance can add some margin left Auto with some right pad with some margin right value to have it positioned on the right side. As you can see here. So that was the composition approach. So obviously the composition approaches extremely flexible, right? Because you just basically use the components which are building blocks. to compose the functionality If you for instance need something more custom you can just create new markup right custom markup or you can add more building blocks and that's that. So yeah, that's why composition approach is really flexible. And it's not hard to you know, extend functionality or and you don't really even have to override anything right because you just compose everything. So yeah, it is very easy to create different functionality in the UI variance. with composition approach However, there are some cons to this approach right because obviously you need to compose the building blocks yourself right to create this file function fully functioning component or feature. Because of that you need to know how the building blocks work what they do and how they should be composed. This isn't the case when using the configuration approach because with the configuration approach you basically just need to know what probes you're supposed to provide and that's it. In the configuration approach we see the component just takes care of everything right under the hood, but you don't know you might not know what's going on there. You just need to know the props and what values in the past and that's that why would the composition approach you do need to know what the building blocks are doing and how they are how they should be used. And well obviously another cone is that it does take more time and code right to create the same thing because again, you need to compose the building blocks yourself. And another disadvantage is that it's much easier to diverge from the design system and shipping consistent UI and behavior. Well, obviously because you basically can compose the breathing blocks, you know, however you want. Right? So it'll be easy to make mistakes and shipping consistent you I just basically by providing wrong classes or are there in the building blocks in the wrong way. This isn't the case with the configuration approach. Because again, you just provide props and that's it. So again, both approaches have the processing cost right? So question is when should we use which one? well technically why not both right because what we can do Is first use the composition approach to basically build the well create the components that are the building blocks, right? And then we can use them to create a configuration configured component. Like here we have an example. Again, like we did in the configuration project example, we receive a number of props right for the alert then. We have the base valid component. And which basically accepts the variant and class name? Then we also have the alert icon if the iPhone was passed any prendered. and other content where if they had there was passed and alicator component will be rendered and if the text or children were passed then other body will be rendered with And yeah, that's how you can combine composition and configuration approaches to basically build components. So most of the time just you can use a configured component, but if you need more flexibility, right then you have this building blocks available for you. So in summary composition approach offers more flexibility, but it does require more knowledge of how to compose the building blocks right how they work. On the other hand configuration approach is less flexible, but this simpler to use and makes it easier to stick to the design system. But yeah, we can combine both approaches to get the best of both worlds. So you can find code examples for this presentation in this GitHub repo. What's more if you'd like to learn more about Advanced patterns best practices techniques for many crucial content that Concepts? Such as local and Global State Management scalable project architecture performance optimization managing apis testing and much much more. You should definitely check out reactor Auto Enterprise. And yeah, if you'd like to get in touch, you can find me on Twitter LinkedIn code mentor and 02 Enterprise platform as well. That's it for today. I hope you I hope you enjoyed the talk and have a great day.

Thomas Findlay

Find Out If Your Design System Is Better Than Nothing

 Design system is worthless. If not used design system is a tool it's not enough to exist. It has to actively be used to make the product better or help deliver it faster. That's the only way for design system to be valuable. Building and design system without getting sufficiently adoption is a waste of time effort. My name is arsenic. I'm a solution architect at Wrangle Amsterdam in the stock. I will tell you how to measure the adoption of a design system based on the metric I set up recently for one of our clients. Conversation about metrics acquires data showing your data from a corporate client is unfortunately not possible. So I found an open source substitute. I will use grafana as an example. If you don't know. Grafana is a devops monitoring platform. It's an old and big project. It was Rewritten from angular to react starting around 2018. It has an ecosystem of plugins and most importantly for the stock. Grafana has a design system. It's called grafana UI. In their store intro they say that they built it to get a shorter development cycle and a consistent user experience. These goals are in line with what you'd expect to find in a corporate design system. I want my products to look like my products and I want to build them faster. Let's take a look at how well grafana you wise doing. On this chart we're tracking how a project and its ecosystem evolved and how they adopted a design system. Horizontal timescale is five years measurements are taken at weekly intervals. Vertical number is graphana. UI component usages usage is when a component is referenced in code. We'll discuss later what it means but simplified it's when you mention a component in a GSX tag For the sense of scale last week at the right edge of the chart. Grafani UI components were used more than 7,000 times cross grafana itself and 290 of its plugin code bases. What picture does this chart show you the line goes up number of usages grows consistently over time. Is it good for the design system? Does this mean a design system is getting continuously adopted. The answer is you don't know. The reason you don't know is competition. I'm an engineer. I can use a design system. I can use third party libraries or I can build my own components. Developers have a choice of how they build things. This is particularly true for the open source plugins in this analysis. If I build a plugin and host it on my own GitHub account who can force me to use grafana UI. The only option to affect my choice is to make a good design system and make it easy to use. Even if your product doesn't use any third party libraries in any project that are going to be Homebrew components. Homebrew are the low level components implemented directly in the product codebase. You build your own button. That's Homebrew. It's very important to focus on the low level components. We're not looking to find every possible component usage. We're looking for the competition. Component online 2 is not Homebrew because it's compositional it only uses other components compositional components are expected in any code base and don't completely compete with the design system. Component online one on the other hand is Homebrew. It uses lowercase jsx tag has opposed to capitalized one. That way. We know it deals with raw markup because it deals with raw markup. We counted as Homebrew. Now that we know what we're looking at. Let's end Homebrew to the chart. This is the same chart as before same access same data except with Homebrew usages added on top. I want to point out the scale once more. We're looking at combined 11,000 component usages at the right edge of the chart across 291 repo. Total shaded area is almost a million usages. Those are not unique sensor tracking code over time. What can you see on this chart gray area at the top representing Homebrew starts before red area representing. Grafana UI at first. There was no grafana UI. Both lines are growing while the use of the design system is growing. So does Homebrew the fact that the two lines are growing means it's a project and the ecosystem are growing. They look healthy. The shapes look pretty similar in particular over the last year the bumps on these lines are features every significant change set adds a bump or a dip to the line because it means components are used more or removed from the code base. But notice that the shapes are not always mirroring each other noticeably around 721. Mark lines not being similar means a component Source mix is changing. Imagine you have two buckets Homebrew and grafana UI you take components from both buckets and compose to make your feature buckets. Are your sources how much you take from the buckets is your Source mix Source mix changing means you're taking more or less from one of the buckets then you did before. We can infer from this chart the two sets of factors affecting design system growth how the project grows grows and how the design system itself is doing. Do isolate the design system adoption from the project growth and other factors we have to look at how the source mix changes over time. And this in my opinion is the single most important chart for design system. This is a source mix changing over time. It's a proportion of Homebrew to grafana UI usages. The size of a code base is not fixed it grows and sometimes shrinks over time. But each feature has limited opportunities to use the components. Out of the set of competing components doing bloated the same thing. You're only going to use one in each case. This means choice of the component source is a zero-sum game. If you use a design system, you're not using Homebrew and vice versa. So the chart you're looking at shows displacement. It represents a graphana UI taking over the choices developers make when building things. More and more developers are choosing to use grafana UI over Homebrew components. Something as you can notice about this chart in the beginning there was only Homebrew. Grafana UI did not yet exist. Then you see drastic jump when existing components are pulled into grafana UI for the first time the project was still small. And so this creates a big change in proportion. When you see a period of growth for a couple years and over the last year displacement almost stopped. Refiner UI reach the limit of what people can do with it in its current state the mirroring of the two lines that you've seen on the previous chart is almost perfect for the last year because the source makes did not change. Grafana UI reached a state where each new feature uses the same mix of a design system and Homebrew components, even if the components themselves are different. Why is this chart so much better than the previous ones? Source mix is independent of project growth team size level of investment Etc. You double the team size tomorrow the chart remains valid. It removes any volatility due to Features. The only changes are the source mix nothing else. Basically, it shows team preference for the design system over the competition. Interestingly it also accounts for availability if I'd liked the design system component, but I can find it. I'm more likely to use Homebrew. For a business or a product you might look at the market share. This chart is market share for a design system within the project. Your Design system better than nothing if you do nothing if you don't build the design system at all, the product will still exist the features will still be built using other components If your design system fails to displace the competition the shared takes across the component usages will diminish over time from the starting positions. That way watching grows faster than the design system gets adopted and features. Don't use it much. If the design system is successfully displacing the competition. That's how you know, it's doing well. Brings me. To property of this metric up is good. Down is bad. The chart goes down for a while. Something is wrong if the child goes up keep doing what you're doing. So it cannot go up forever. No matter what the coach says, you can give more than 100% Even if you do everything absolutely right line will go sideways at some point. What's inappropriate sideways level for a general purpose design system. Ideally, you should reach a level where there is no other Homebrew components except for snowflakes. Snowflakes are those truly unique one-of-a-kind Homebrew components. Imagine you're building a landing page for a million dollar ad campaign. It's okay to have a bunch of unique components specifically for that situation. Having snowflakes in the project is okay and probably unavoidable if you only have snowflakes among Homebrew components you're doing a fantastic job. You might not reach that level. If you only did the very Basics don't expect line to go to high. If your code base has too much Legacy. Don't expect the line to go too high too fast either because refactory Legacy is slow. So displacing Legacy is slow. And the level you reach the pendant goals. If you're focusing on a specific use case, for example getting product images just right for e-commerce, then it's okay to not get too much adoption relative to all the Homebrew in the project. If you have a specific Focus, you need to adjust your definition of the competition to get meaningful metric. Remember that Homebrew definition so far was any component rendering role markup? You could share is a code-based metric. If it doesn't go as high as you want, you might be tempted to call out those basket Developers for meddling with the adoption success. That's not correct. Design system requires governance deciding what goes in and what doesn't it requires a lot of collaboration between different people across the organization designers developers and product owners. Lack of adoption might be caused that any point in the decision-making process. If a designer doesn't like the system, they will not incorporate it into the designs. So the developer won't use it either. This measurement sets at the tail end of the development process. So it's affected by all the choices involved in it. The analysis is still valid though, because in the end software product is code and the design system is shipped as part of it. For this analysis to be useful. It has to become a part of your governance process and for that it has to be cheap and repeatable. You should be able to run it every Sprint to see how things change to react and to plan farther work. Fortunately we can automate it. Let's talk about grammar. Here's a famous example of gibberish. If I ask you to tell me what the statement is about, you should see be able to say that it's about ideas doing something. You should be able to find the subject. Notice that the phrases designed to have no meaning yet. We're able to make some judgments about it based purely on syntax. Surprise computers can read code in Practical terms. It means code is formal. It has strict syntax. It has to be formal for the machines to run it. We can teach a computer to read code and find patterns in the structured statements. This is called Static code analysis. Just like this chomsky's nonsense. We don't have to run the code to figure out what it's doing. It's enough to look at code. You're probably already using tools that read the code programmatically your lender does static analysis to find issues with without having to understand what your code is doing. Let's take a look at the syntax of a component. We've seen this code before how exactly do. We know that Homebrew here is indeed. A Homebrew component react component is a function returning just sex. Or a glass with a render function if your old school. Both Homebrew and not Homebrew are components. They're both functions returning jsx. On top of that Homebrew mentions a lowercase Dag. Let's reiterate to detect The Homebrew component will look for functions in functions. We look for lowercase jsx stats, if the function contains a lowercase tag, it's a Homebrew component same for classes. When doing this analysis, we assume the code is valid because it has to be correct to get shipped to production. If you're shipping invalid code to production. You've got bigger problems and I can't help you on top of that. We assume the code is saying It's really hard to write a program that would analyze all possible JavaScript the code. You see also creates a react component. I don't think it's reasonable to try and parse code like this because this code is not the same good thing that humans tend to not be able to read code like this very well either. If someone on your team is shipping this to production you've got bigger problems, and I can't help you. I promised earlier to tell you what is a usage tag online 2 references a button identifier Define online one such a reference is a usage of a button component. JavaScript is typically not as simple as that, so things can get a little little bit more complicated. Interact user like this is still a usage of a button. We've taken a button assign it to another variable and referenced that variable this still counts. take two files one where you export the button and one where you import it, there are multiple ways to import including aliases and namespaces or re-exports importing is extremely common and we have to keep track of it usage of the button on line 6 should count Notice it's possible to track usage of a button starting from the import at line 5. We don't need to know what the button is. Only the package export something called button and that thing later gets used. This way we can track usages of a design system imported as a package. You have a button you put it into the object and spread it into props. You have now passed the button as a render prop. It's still a usage of a button. We don't know what happened to the button inside the component. We know that the button is likely to be used. Another common use case is higher order components. notice that the button is used not when the higher order component is created online 5, but when it's used online 6 and 7 every time the hoc is used the original button component is also used this code counts as two usages of the button. The reason I'm going through these cases other than to show off. The sophistication of my tracking tool is to point out that usage in code is not a well-defined concept. For the machine usage only exists at runtime. We're not analyzing for that code. We're not figuring out how often something gets rendered for a user in the browser. If we're looking at the static code, we have to Define what usage means based purely on the syntax. Given all the ways JavaScript can be written that definition depends on what you consider usage. My definition is implemented in the tool that I'm using to collect the data. It's called radius tracker. I'll give you a link to the end. Now that you know how to detect Homebrew and find usages. Here's how to calculate the metric. Find Homebrew components find design system Imports collect usages of both calculate the source makes proportion and repeat for historical commits. I've used Button as an example throughout the stalk so far, but not all components are created equal. If you compare an abstract button and a date picker, you'll probably find that each use of a date picker is worth much more than the use of a button because datepecker is a bigger more complicated component. For more meaningful chart you have to Discount simpler components. This means adjusting the weights by component complexity. The chart you've seen before treat all components the same. For the client I mentioned in the beginning we ignored all usages of components like box or typography because those are valuable even a significantly overrepresented in the code base. If you take one thing from the stock build what is valuable for your team? And then measure the usage share percentage to see how much people prefer what you're doing over the internal competition. To run this analysis yourself grab the radius tracker. We wrote in Wrangle. It's open source, and I suggest you check it out. Ask me for advice and reach out to Wrangle for practical help. Thank you.

#component library