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 task a few years ago, it was a success on one end, but a 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 we had to change something in the code, for example, a rebranding effort, new colors or a new interaction, accessibility was 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 code worked functionality wise, but if you look under the hood, it was full of patches, full of hacks, not something we 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 a maintainable way. And if you're tackling the same problem today or you're trying to make your application accessible in a way that will last, this talk is for you. So let me start. This talk is called my accessibility journey, the quest for an accessible component library. Or as should the full name be, my accessibility journey, the quest for an accessible component library that refactors and redesigns and is maintainable and testable. Which are small points, but they are very important for us to have accessible code. So let me introduce myself. I'm Asaf. I'm the father of Sarah, Eitan and Aziv, married to Neta. I've been in the web development field for over a decade in various roles. And currently I'm the front end tech lead for Evinst, which is a startup that specializes in giving developers great developer tools for accessibility. For example, we have algorithms based on computer vision and machine learning that help detect and find accessibility issues. We create Chrome extensions and other extensions for mobile as well that 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 a short while in this presentation. So let's start. Before we start, what is accessibility? Accessibility is about inclusion. It's about letting everybody in. Letting all the people use your amazing application. For example, a person who has a physical disability and cannot use the mouse will still need a way to navigate through your website and to click on your dropdown and to select the third option that opens another submenu and then to select the fourth option from there. So if you have some kind of navigation or some kind of interaction for the users that we all have in our applications, you must 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 these kind of things from leaving our code. We want to ship only code that is accessible from the start. So when we want to make our own application accessible, we thought about 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 the accessibility of the product flow by flow. For example, we can cover the login flow, start with the login screen and then to confirm that the login popup is valid, that the ForgotMyPassword 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. Sorry for my voice. I have a bit of a cold. Thank you for completing it in your head. So another option is to go page by page. If we go page by 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. Every button can be accessible by keyboard. Every form has a label that a screen reader can tell the person who is looking at the website what the label is. But there is a third way that comes more naturally for us as developers. And this is by thinking about components, because as front-end developers, we tend to think about the world or about applications as built out of components. For example, my website is built out of buttons, forms, popups, labels, input fields, maybe drop menus, select boxes, check boxes, and we are doing composition, like we're taking this component and that component and we assemble forms or assemble graphs or assemble pages that have a big table and a menu and some text field. And as an 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 a valid way. Also pages. But components we love. And this is the recipe that works for us when 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 needed to identify the common components. And maybe change the API so it will be the same for all of them to match all of the use cases. And then we put them in a separate Git repository. But first it starts by identifying which components 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 are 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. It will come to your house or to a place that you want. And it will pay your visit for a small fee. It's a great website. If you find the real one, please let me know. I'll use it for sure for 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 a drop-down here that you can select the location. And there is a date picker. 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 a hover state, like when you hover over it or when you focus it with a keyboard. Maybe it has some kind of tooltip. Maybe the tooltip has a specific design or a specific appearance in specific cases. Same for the drop-down and same for the date picker. It can be a pretty complex component. Now after we identified these components, we are separating them from our repositories, from our product repositories, to a common repository, which is 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 afterwards, we consume this by all the products. And this component has different size building blocks. It can 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 it has a sorting mechanism and you have some kind of error handling inside of it. I mean, it can be a 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 visualize the components and also the basis for our tests, which I will show you in a little while. And we use Cypress for tests and CircusCI for continuous deployment. Okay, so the second part, now we want to create an accessible component. So let's make an accessible button. Let's create an accessible button. What does it mean for a button to be accessible? Let's think about it. Well, some of the characteristics that make a button accessible is that if you cannot use a mouse, like we said before, you should be able to focus on that button 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 buttons is in focus. And then if you 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 a button. So it will know, it will tell screen readers or other assistive tools that this is a button. Okay, now when we have these demands in mind, let's go into the code. So this is a 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 onClick 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 tabIndex attribute. The tabIndex 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 keypress. And now we need to filter these keypresses 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 spacebar, we should also trigger it. Depends on the operating system. I'm not sure. But some things 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 state, disabled state, primary mode, secondary mode, maybe a mode for a button with images. Maybe it should have like specific state for specific pages. I mean, the code will only increase from here. And this code actually doesn't even cover all the accessibility aspects. It needs a lot of code. What if I tell you there is a different way? An easy one. What if we would just use HTML button tag? So what will happen if we use the HTML button tag? 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. We will get the on key press and we get the role 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 us lots of time in testing and will just give us features for free. This is true for buttons, but it's also true for input fields, for labels, for headings, for other attributes. Okay. And let's talk about adding a level of automation. So to 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 the thing that interests in here is the primary prop. We said that is it a primary or secondary button. Now we take 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 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 won't miss it. If you click it, it opens the component in a separate tab, actually without all the wrapping off 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 functional and accessibility testing. So this is our functional test. We will use Cypress for it. And the 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 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 find? Some of the things that we wanted 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 popup but the popup is not accessible or we have text in some color and 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 we are working on in events. These are kind of the things we are detecting using our engines. So because we work in events, we want to use our own tools. So we use our own tools also for test automation. And we do it by providing an SDK for Cypress that gives us the ability to gather accessibility issues. So if we call EV start, this is the command, it says, events, please start gathering accessibility issues. And then we do some things and we call EV stop and then it gathers all of the issues and we can run our validations against these 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 we run the functional test, we call EV 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's related and the selector that it's related to the contrast between the text color and the background color. To be more specific, there is a contradiction, a bad contrast between RGB 100, 4100, 400, 0609 and white. Well because I'm not a qualified designer, sorry, I'll do what any good developer would do. And we say, let's replace it with black and it works. Now the color contrast is great. In real life I would consult a designer, but this is a talk and I'm alone here. 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 140 components, more than 170 stories and tests. Each story is covered with both functional and accessibility tests. It's used across four projects. We are a team of six people, almost seven people. It depends on your count. And this library and this approach saved us saved our accessibility doing a huge rebranding effort we just did. So we changed basically both of the components were changed, but 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 to know your HTML text and automate as much as you can. Automate 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 Ph.D. in accessibility to start your accessibility effort. 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 here in the conference. I will be available in the Q&A session in a 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 will assault. Thank you.


Asaf Shochet Avida

Developing and Driving Adoption of Component Libraries

Hi there, I'm Lachlan, and today with my colleague Logan, we'll 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 how we 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 a 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 picker, 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 output, meaning if multiple teams are using this component, 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 a user's 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 recognize you don't need to and can't really cover 100% of use cases. So instead we aim for the common 90% and try to make the remaining 10% easy for teams to do themselves. So therefore, we start near the 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 hard because most frontend 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 this spectrum 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 somewhat. But this can involve 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 now 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 its ease of use and to providing a consistent look and feel. So here on the right hand side, we have a demo component, which is a dropdown list box, 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 our list 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 a 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 V1, 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 mark an item as new, and this is really nice. But what if the team needs one item to have more than one tag? An item could be new and also sold out or an item could be popular and new. Or maybe we'll want to change the color of these tags so they're more identifiable. For example, green could signify some kind of positive connotation, maybe used for new items while red could be negative, used 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 could provide more than one. But this is really just to 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 of our component. And this uses an API that we use a lot internally at TikTok in our libraries. So version 3 of our list box 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 it really useful. So here, let's configure how the button 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 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 label and value, we've now added the additional properties is new and is sold out. And our render method not only shows the label, but 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 list box. 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, this is just generic type. Product team can just add more properties as they need. So maybe we have is popular on one of these. Maybe the banana is popular. Cool. And maybe if it's popular, we could add a popular tag. And you can see the type inference 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 don't need tags really, but maybe they need something like an avatar picture to show what the employee looks like. Or maybe even an online offline indicator. So let me bring up an example that I made earlier. And you can see, again, our items basically have now an avatar and an is online status. And the render method, if we look at render item, we're also optionally adding an avatar. And again, this is a component library that we're using. So it's really nice. We're able to compose things in this way. So if you have a look on the right, we can mark employees as 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 hand it over to Logan. Hey, everyone. I'm Logan Ralston, a software engineer at TikTok. And I'll be giving the second part of this talk today. So Lachlan already talked to you about what factors and balances 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 APIs at TikTok. So brief intro about me. I'm Logan. I work on the Tux component library, which is TikTok's internal UI component library. And some of my work is on the infrastructure surrounding design systems. So static code analysis tools, like we'll talk about in a second. Linting, code mod kind of stuff. So let's start with how to measure a component library's effectiveness. So when Lachlan talked about what makes a component library good, he referenced a couple of kind of abstract quantities, like flexibility and rigidity that we can describe a component library in terms of. There's also like brand unity, developer productivity, and then increase to code quality. These are all things that we want to find just to optimize. We want to have high developer productivity, high code quality, obviously. But they're hard to measure in practice because they can be quite abstract. So when it comes to finding heuristic we can use to represent these, one of the primary ones that we use is adoption rate. So adoption rate is really important because it measures how much an engineer actually wants to use your components. Because let's say your components aren't flexible enough. So 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 going to have to go build their own component, which is going to be a huge waste of developer time. And it's also going to lower your adoption rate. And similarly, if your component library is not rigid enough, it's way too complicated, there's way too many options, the developers are just getting lost in some malaise of various configurations, then they're not actually going to use your component. And your adoption rate is also going to go down. So adoption rate is a primary heuristic because we know if that goes up, we're doing something right. So there's actually a variety of ways to measure adoption rate too. But one of the primary ones we use is component coverage. So component coverage is just the ratio of the number of times somebody is using one of your components to the number of times they should be using your components. So we call the times that they're actually using your components, good cases. So we're going to take TuxButton, our button component, for example here. So just every time they use the JSX element TuxButton in the file, that's a good case. They're doing something right, they're using the right component. And then every time they're using something like my own button or an anchor tag with the class name of BTN primary, that's probably going to be a bad case. That's something that they should be using TuxButton instead for. And then let's say that, given a source code file, they use TuxButton three times and they use a combination of my own button and an anchor tag with the class name of BTN primary nine times. So then we're going to say that in this file TuxButton has a component coverage of 25% because it's three good cases over 12 total cases. So three over 12, 25%. Now one thing to note here is, while it's possible to accurately determine the number of good cases completely, the bad cases is actually a text inference problem. So the logic there is a little fuzzy. So you can never guarantee bad cases is calculated perfectly. But that said, 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 repo level. So we look at all the code bases that we have internally, we say which ones are using Tux and which ones are should be using Tux. And we can calculate a coverage ratio for that too. We can look at the version distribution, which ones are stuck behind on old versions of Tux and not actually using the most updated 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 can enforce some semblance of code style or brand unity or whatever construct through here. We can look at the rate of bug fixes or feature requests over time. We can look at linting rule violations that are related to the component library. And there's many more metrics that are useful to collect. So how do we actually collect this data? So the primary way we do this is we, for a tool called Tux scanner, so Tux 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 Tux is being used in practice and sends us data all off to an API so we can go and analyze how the Tux is being used. So we start here. We have a file source code. We parse into an AST, 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 all give us scores. So it could be like 80% component coverage before or maybe there's 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 to do a little bit of a deeper dive into how scanner works, so we start by parsing the source code files into ASTs, abstract syntax truths, which is just a tree representation of the source code. It shows how all the constructs of the language are related. So like the JSX elements related to the class name attribute and have a tree based on that. And this just allows us to go through and evaluate a set of metrics on there. So a metric is just a function that takes in a set of ASTs. It goes in and traverses those ASTs 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 to improve our score. The call sites of the good and bad cases, which are just the links to the nodes, usually it's JSX elements, but it could also be like, say, like an input declaration or something, just a place in the code where something's going wrong. And then the coverage scores. And then when 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 TuxScanner has collected all this data, how do we utilize it? So at TikTok, 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 to stay nimble and keep on evolving. So we need to be able to keep what's working and throw out and redo what isn't. Now, this is a good truism for how code should best be maintained, but it's not often practiced. 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 hard and introduces a lot of maintenance. But we can't look at these things as for the lens of being a maintenance burden. We need to always be striving to introduce breaking changes in order to go and reach for that asymptotic platonic form of what a component library should be. And we can't abandon that for the sake of stability. We've got to stay nimble. So we cannot be afraid of introducing breaking changes to our components. In fact, we want to be making them regularly. We've got to embrace the breaking changes. So this is easy to say in theory, but it's hard to do in practice. And at TikTok, we've made a concentrated effort to streamline our architecture to facilitate this. So one such example is we use a monorepo. And in a monorepo, almost all of our consumers are on the latest version of Tux. And this means consumers aren't left behind. Because let's say we introduce a bunch of breaking changes and release version 5 or whatever of Tux, but a lot of consumers are on version 3 because they want to have to go through an update to all 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 in practice, they're just all being left behind and it's kind of pointless. So this means that whenever we introduce a PR that introduces a breaking change as part of that, we've got to go and update the majority of our consumers to use the latest version of Tux because the majority of our consumers are always on the latest version of Tux. And this means an important philosophy that we have to enforce this is the one of co-ownership. So at Tux, 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 and update all the call sites for code mods or whatnot and make sure they are on the cutting edge and that they aren't left behind. Okay. So quick summary. We talked about what makes a component library good. We talked about how to quantify a component library's effectiveness and we talked about how they use that data to help 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 Tomasz Findly, and I'm a full-stack web and mobile developer with 10 years of programming experience. I'm a co-owner of Findly Web Tech, as well as a mentor and consultant at CodeMentor.io platform. Besides that, I'm the author of React.io to Enterprise and View.io to Enterprise books. I also write articles for Telerik and York to Enterprise blogs. That's enough about myself. Now components. So let's be honest, building future-proof components is not easy. If you have a component like this, it's very simple. So for this example, I will use an alert component. So for example, if you would want to have an alert component that would display a key alert message, well, we could do something like this, right? We could receive text and children as props, have some diffs with styles, and then render what was passed, right? And here's how we could use it. Just use the alert 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 extend. So what if we would want to add more features to this alert component? Let's say we just 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 alert header and the text message. So that's quite simple still. Now, what about variants? 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 appropriate styles. So for instance, we could support variants like success, danger, warning, or info, as you can see on the right side. And that's how we would use it. We'll just pass header and variant props, and some text inside. Okay, so what about adding maybe an icon? Well, again, another prop, like icon. If it was passed, and we found a supported icon, then we can render it. Simple, isn't it? And that's how we could use it. So basically, by default, the icon could be displayed on the left side. But what if we would want to actually be able to specify on which side we want 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 prop like icon position, right? By default, we could set it to left. And then if for instance, it was right, we could specify some classes, right? That'd be added on the alert container. Note that I'm using Tailwind here for classes. And yeah, that's how we would use it. So 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, for 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 a component or even extend it. So that's not really the best. The configuration approach makes it much harder. So 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. So yeah, basically, different functionality and visual variants can be controlled via 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 and that's it, you can't do really anything else with it. So, well, this keeps the UI and behavior consistent. But yeah, like I mentioned, the problem is that we can't easily extend configuration, build component or override it. So what can we do? Well, I mean, we could obviously provide maybe props like, let's say, render icon, render header, render body, and so on and so on. But again, more props, it would be just more messy. So it'd be more conditional logic inside of the alert component. So instead of trying to configure everything, how about we'll use a different approach, composition. So in this example, we have three components, first the alert wrapper, then alert content and alert body. And to the alert body, we pass the text message. I know three components just for the text message is a bit much, but stay with me. So how it could look like? Basically the alert component, obviously, it would receive some props. Then it would render a div with appropriate styles and children, right? So in this case, the children would be the alert content and alert body. Then we have the alert content. As you see, it's very similar to the alert component. Because again, it just receives the props and has a div with some styles. And actually, well, the same will apply to alert 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 this is a contract example. So yeah, that's how we use it. Now, if we would want to add, let's say, an alert header, well, we don't need to add a 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 say, so first that. Again, alert header in this case also is very similar to other components. It just receives the props, renders the div with correct styles, and then finally the children. Now, next, what if we would want to have variants? Well, I guess maybe we could actually pass one prop to the alert component. Of course, we could also create a component for it. But for this example, this will do. So we'd pass a variant prop to the alert. But now the thing is that we can compose the components to build the alert functionality. But the thing is that we can also use not only the building blocks, the components that we build specifically 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 these building blocks, just the alert component. So how do we provide a variant to all these other components, like alert header and alert 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 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 appropriate 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 factory 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, 1.5 here, the use variant context is exported so that it can be consumed in alert components. And then in the variant context provider, we basically just render the provider and pass the variant to it. That's it. Next, so here we have the context factory. Basically it creates the context, creates the consumer, and returns them. Now alert header. Yeah, so we need to now update the alert header and alert body component because they now also need access to the variant. So we import the use variant context hook. We consume the context, and then we use it to apply appropriate styles. And we do the same in the alert body. Again, consume the context and apply the styles. Okay. Next, so we have alert component with variants and icons. So if we wanted to add an icon, again, another building block, we can just use a component that was already built as part of the, let's say, all the alert components and pass the specific icon. Or if we would want, we could even add some custom markup for it. Now how would we use it? So first, we can have an icon config map where basically the icon is mapped to, let's say, SFG icons or whatever 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 markup for it. Besides that, we also consume the variant context so we can add appropriate styles 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 for 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, it 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 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 approach is 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? New 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 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 and UI variants 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 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 props you're supposed to provide. And that's it. In the configuration approach, basically, the component just takes care of everything, right? Under the hood. Because you don't know, you might not know what's going on there. You just need to know the props and what values you need to pass. And that's that. While with the composition approach, you do need to know what the building blocks are doing and how they should be used. And well, obviously, another con 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 ship inconsistent UI and behavior. Well, obviously, because you basically can compose the building blocks, you know, however you want, right? So, it would be easier to make mistakes and ship inconsistent UI just basically by providing wrong classes or ordering 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 their pros and cons, right? So, the 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 configured component. Like here, we have an example. Again, like we did in the configuration approach example, we receive a number of props, right? For the alert. Then we have the base component, which basically accepts the variant and class name. Then we also have the alert icon. If the icon was passed, then it will be rendered. And alert content, where if the header was passed, then alert component will be rendered. And if the text of children were passed, then alert body will be rendered. 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 these 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? And how they work. On the other hand, configuration approach is less flexible, but it is 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 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 React. The Road to Enterprise. And yeah, if you'd like to get in touch, you can find me on Twitter, LinkedIn, CodeMentor, and the Road to Enterprise platform as well. Well, okay, that's it for today. 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 a design system to be valuable. Building a design system without getting sufficient adoption is a waste of time and effort. My name is Arseny, I'm a solution architect at Rangel Amsterdam. In this talk I will tell you how to measure the adoption of a design system based on a metric I set up recently for one of our clients. Conversation about metrics requires data. Showing you 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 this talk Grafana has a design system. It's called Grafana UI. In their storybook 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 UI is doing. On this chart we're tracking how a project and its ecosystem evolved and how they adopted a design system. Horizontal time scale is 5 years. Measurements are taken at weekly intervals. Vertical number is Grafana 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 JSX tag. For the sense of scale, last week at the right edge of the chart Grafana UI components were used more than 7,000 times across 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 this 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 there are going to be Homebrew components. Homebrew are the low-level components implemented directly in the product code base. 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. ComponentOnline2 is not Homebrew because it's compositional, it only uses other components. Compositional components are expected in any code base and don't compete with the design system. ComponentOnline1 on the other hand is Homebrew, it uses lowercase JSX tag as opposed to capitalized one. That way we know it deals with raw markup. Because it deals with raw markup, we count it as Homebrew. Now that we know what we're looking at, let's add Homebrew to the chart. This is the same chart as before, same axis, 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, though they're not unique since we're 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 UI is growing, so does Homebrew. The fact that the two lines are growing means that the 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 the 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 than you did before. We can infer from this chart the two sets of factors affecting design system growth. How the project growth grows and how the design system itself is doing. To isolate a 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 a 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 broadly 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 Grafana UI taking over the choices developers make when building things. More and more developers are choosing to use Grafana UI over Homebrew components. Some things 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 then, so this creates a big change in proportion. When you see a period of growth for a couple of years, and over the last year, displacement almost stopped. Grafana UI reached 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 mix 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 like to use a design system component, but I can't 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. Is 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 share it takes across the component usages will diminish over time from the starting positions. That way, the project 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. Which brings me to the basic property of this metric. Up is good, down is bad. If the chart goes down for a while, something is wrong. If the chart goes up, keep doing what you're doing. Though it cannot go up forever. No matter what the coach says, you can't give more than 100%. Even if you do everything absolutely right, the line will go sideways at some point. What's an appropriate sideways level? For a general purpose design system, ideally, you should reach a level where there is no other Homebrew component 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 the line to go too high. If your codebase has too much legacy, don't expect the line to go too high too fast either, because refactoring legacy is slow, so displacing legacy is slow. And the level you reach depends on 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 a meaningful metric. Remember that Homebrew definition so far was any component rendering raw markup. Usage share is a code-based metric. If it doesn't go as high as you want, you might be tempted to call out those pesky 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 at 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 sits 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 further 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 this statement is about, you should be able to say that it's about ideas doing something. You should be able to find the subject. Notice that the phrase is 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 with 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 linter does static analysis to find issues 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 JSX, or a class with a render function if you're old school. Both homebrew and not homebrew are components, they're both functions returning JSX. On top of that, homebrew mentions a lowercase tag. Let's reiterate, to detect a homebrew component we look for functions, in functions we look for lowercase JSX tags. 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 sane. 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 sane. 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 on line 2 references a button identifier defined on line 1. Such a reference is a usage of a button component. JavaScript is typically not as simple as that, so things can get a little bit more complicated. Indirect usage like this is still a usage of a button. We've taken a button, assigned 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, 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 that 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 that the package exports 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, but 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 on line 5, but when it's used on line 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 dead 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 data. It's called Radius Tracker, and I'll give you a link at 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 mix proportion, and repeat for historical commits. I've used button as an example throughout this talk 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 date picker is a bigger, more complicated component. For a more meaningful chart, you have to discount simpler components. This means adjusting the weights by component complexity. The charts 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 aren't valuable, even if significantly overrepresented in the code base. If you take one thing from this talk, 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.


Arseny Smoogly

Walking the Line Between Flexibility and Consistency in Component Libraries

GraphQL Galaxy

GraphQL Galaxy 2021

Putting the Graph In GraphQL With The Neo4j GraphQL Library

William Lyon

Tooling and Processes for Managing GraphQL at Scale

Mark Larah

Building Cross-Platform Component Libraries for Web and Native with React

Hello everybody, my name is Perttu Lähnälahti and today I'm going to talk about how to build cross-platform component libraries for React and React Native. Before I dive into that subject, I just want to introduce myself briefly. My name, as mentioned, is Perttu Lähnälahti. Don't worry, it's a really difficult one. I had it wrong once even in my passport. The reason for the difficult name is because I'm originally from Finland, currently living in this beautiful Helsinki, Finland. I have a website, Perttu.dev. You can find this presentation as an article there and also a bunch of other stuff as well. You can also find me on GitHub and Twitter using this handle here. And the slides for this presentation, you can find them at this address. You can also find this project there, which will allow you to test it out and build your own components using the way I'm going to show you. So yeah, let's dive into the subject of today's talk. So what this talk is going to be about is, of course, how to build cross-platform components so that you can actually use them in both React and React Native projects. My idea is that the requirements for React Native knowledge are going to be pretty slim. Just knowing the basics of difference between React Native and React is supposed to be enough in this case, and I hope it's going to be. Using React Native, we're going to look into how to actually use that to build cross-platform components that we can use on both web and Native, in this case iOS Android, and also how to build these platform-specific components so that we can have the same components, but the code being different between these two platforms. The reason for this, we're going to talk later more about it, but the basic idea is that we want to have a single code base and share as much code as possible. Towards the end of the talk, I'm going to dive a little bit into the styling and the pros and cons of this approach that I'm going to show you. Then a few additional points. So we're not going to use React Native Web. The thing I'm going to mention soon, and we're also going to use Styled Components and Storybook. For those who haven't used Styled Components, it's a really awesome CSS in JS solution that allows us to style our cross-platform components really easily, in this case. Storybook is just something that I'm now using to show the components in a separate context from actually building a real application. This project or this approach that I'm going to show you is actually based on a customer project that I did a little bit of time ago. So that customer, I can't mention the names, but it's a big government owned news organization. They actually had three React Native apps and one web app that was powered by React, basically their main website. They were serving, I'd say, close, maybe even over a million people every day. So the user amounts were huge. My team was asked to build a new feature that would allow live content on their platform. This would mean video, polls, chats, and of course, live updated articles about different things. There were a few requirements. So despite having these three or four different platforms, four different apps, they actually wanted a single code base. So this feature that we would build as a separate component library, it would need to work in all of these four projects, which was quite the requirement. And it also needed to have a unified experience so that it looks and feels same, despite you using it on a different app, different native app, different web app, and so on. And time schedule was also really tight. So I think they wanted to get an MVP out in less than three months or so, which for a company of their size was quite a big undertaking, but we managed to get a pretty good version out. Now, some of you who've used React Native and perhaps React Native Vapor are now at this point wondering, okay, this seems like a really good option to use React Native. However, we actually didn't have that choice. So the reason why we didn't use React Native was multitude, but they came down to this. So of course, there were the good things. We could use the familiar components like view, text, and image that we are already familiar with. And the company's developers were familiar with using in their React Native apps. And those are really easy to build for both web and native if you have a completely new React Native web project. However, in our case, it was already an existing and a huge React app. So we couldn't just bundle in React Native there and get that working. But we were limited to having it so that we need to have React code working in React project. And we need to have React Native code working in React Native project. And also in case we were kind of limited also by these view, text, and image components, because we needed proper HTML text like H1, H2, H3 to actually get all the SEO benefits. So yeah, without further ado, let's actually talk about how we're going to do this. How we're going to do cross platform components. So there's actually this feature in React Native where you can actually do platform specific extensions for files. So those who have used React Native already know that if you have an iOS component or Android component or a view, you can just put the.iOS before the.js extension and React Native bundler will automatically know which component to use and bundle in the JavaScript bundle for which platform. And it works really well. What most people I think miss most of the time, because when we did that, there wasn't that many mentions of this, is actually that there's also.native extension, which tells basically React that, okay, use this component in the web app and this one with the native use it in the Android and iOS. And the difference comes from that the other one is of course managed by Webpacks for the web and then Metro Bundler, the React Native Bundler for the.native. And using this, you can actually already create components that work on either or platforms. You can put them in a single repository and use that, but that doesn't actually allow you to build cross-platform components yet. There's still separate components in separate files. But let's dive into actually looking into how to do this. So going back to the editor, you can actually see that this project that I've built, it's a basic React Native type template. The only thing I've added there is the source folder with the components and the utilities folders. Other than that, I've also added two different storybook instances. So there's scripts for running storybook on web and then running storybook on React Native. And that was actually something you just saw here. So if I can go back. So this is actually, these are now the two separate storybook instances. You can see the basic button there and you can see the basic button on the mobile as well. So yeah. Now if we go back to the code editor, we can actually see that let's open up the component for the basic button. In this case, it's called my button. So let's go to the my button file. And we can actually see that that single file that is currently, if we look into the.stories file, we can actually see that it's used by both the native and the React side. And the way that's possible is that my button is a component that consists of button opacity and paragraph. Now those aren't any traditional React Native or React tags that you might be familiar with, but instead they're customly defined. You can actually see that they're imported from this utils.tags file. So let's actually look into that and we can probably get an idea how this works. So let's first look at the tags file. So that's really simple. It's basically, we're just exporting variables like heading one is equal string H1. And React actually is quite smart and can actually handle these as the tag names straight away, which is really cool. And we also have the tags native. And as we mentioned before, if we have these background specific extensions, this means that React Native and React know which one of these files goes to which one. So if we look at the native one, we can see that we're first importing all these image text, touchable, highlighted, and opacity from React Native. And then we're assigning them the same names we have on the text side. So we have the heading one, it's always a text element, a text component. And that actually allows us to build the thing. So we're exporting these two components in the My Brother component and using them. And then when React actually takes this component, it checks that, okay, which one, what is pattern opacity for React and what it is for React Native. And that works. This is actually, this is almost stupidly simple, but it works really well. As I mentioned, we've been running this in production for millions of people. Now, okay, next you might be wondering, how do I actually style this? So if we go back, let's look at the components. So let's open the style button. And on the React Native side, we can see that it's a blue button. And on the React side, we can see that it's a blue button as well. The styles are a little bit different because React Native has a flex one by default, so it takes all the available space. But they still work the same way. So you can click them. They don't do anything, but they are clickable. So then let's look at the actual code behind that. And this is actually where the style components comes into play. So let's open my style button. We can see the style button is okay. It's very similar to my button from the previously. It has the pattern element and the pattern text. But actually, those components are not the same that we imported from the text, but instead they're here below. And using the style constructor, we're passing the pattern opacity and the paragraph elements to the style constructor and then adding styles. And that styles the component. So this way you can actually style cross-platform really easily. It works on both. The style components uses React Native CSS, if I remember right, to actually turn the same CSS styles for the different platforms. And I think that's pretty cool. We're still having ‑‑ we have single code base, but on two different platforms. Now then how about if we actually want to do something with the button? So we want it to be clickable. So if we go back to the storybook, we can see that there's a working button in both. And what that actually does is it works, but doesn't really do much. When you click it on either one, it actually locks to a console that pressed. So let's look at the code behind here. Because this is where we actually will start to see where you have to start to do certain things to still be able to work with a singular component. So let's open up the working button, and we can actually see that there's the on press event that then does the console block pressed. And it's actually being called. I don't have the command line open, but ‑‑ or available for looking, but I can verify that it does show up the press text. And this is actually what enables that. So what's happening here is because on React side, when we're using normal DOM elements, every element is clickable because you use them mainly through mouse. But on React Native, because it's always ‑‑ well, I'd say almost always a touch screen, it's called an on press event there. And if we actually just put on press here, it will complain because it will expect that the button is an HTML element button. And if we put on click, it might actually complain that you don't have the on press event, and on click event doesn't exist on React Native. So we actually have to do this kind of a platform check that, okay, platform, that's exported from you to the platform. What that does is it basically just exports a constant variable on which platform it is. It's a native for native and web for web. And then we do a check here that, okay, which one it is. And we apply the correct prop, whether that is on click or on press for React and React Native. And these kind of things can get a little bit complicated if you have, like, mismatch between prop names between React and React Native. You could easily do a handler for these or like a helper function to allow you to build these more easily. In this case, or you could just do TypeScript hacking a little, that will probably help work as well. In this case, I just wanted to know how, wanted to show you how it works under the hood. So it's not the cleanest, but you're still working in a single code, single file. So it's actually pretty easy to keep check up to actually understand even this conditional code and conditional props. Okay. So yeah, now we have, now we've shown how to do actually functioning components, how to style them so that they're still the same file, but serve from two completely different platforms. How about in a case where we have a, we have a component that is actually the implementation details between the platforms varies a lot. Well, let's, let's actually take a look at that. So let's go back to the storybook and we can see here that we have the WebView component and we open up that. It opens React advanced in a small iframe. And the same goes actually for the React Native app. But this is not an iframe because React Native doesn't have support for iframe. This is actually a component called React Native WebView that we're then just wrapping and assigning the URL as a, as a, as a parameter, as a prop. So, so let's look at the code a little more. Let's open up the WebView components here. And we can actually see a straight away that WebView.native and WebView.dsx are two separate files. So that tells us that, okay, there's a difference between the implementation between the two platforms. On the native side, we can see that that's actually a container. Well, that's just a wrapper that we imported from tags. And then we have errant WebView, which we see that is actually a WebView imported as an error in WebView from the package called React Native WebView. This allows us to use WebView on our React Native app. However, because React Native WebView is, as the name tells, it only works on React Native, we have to have a separate kind of implementation for the web version. So there we can actually see that the WebView component is just an iframe. And despite these being two different components, the WebView.stories automatically knows which one to import. And this would also work if you used it in a real React or React Native version. It would automatically know the bundle would know which component should we use. And hopefully this, you're finally getting the idea of how this actually works. It's really simple. Really easy. And in my opinion, way more maintainable than using, for example, having two separate code bases or adding React Native web to a React project. So yeah. Then let's talk about a little bit why this isn't the perfect solution. So you might have already noticed that there were no responsive design things. The iframe, for example, on the web didn't take the full page or anything or it wasn't matched. Same goes for the buttons. They were just automatically that width. That's partly because doing actually responsive design with style components is really easy. The problem is that React Native doesn't support those same responsive design tags like viewport and so on. Instead, there you have to monitor the viewport size manually through the JavaScript bridge and then change the styles based on that. So usually in those cases, you either have two options. Either you make a helper function to detect in the styles whether you're using whether the component is being used on web context or native context and you apply the responsive design tags based on that or you do a completely JavaScript based solution. Or then third, there's that you separate those two components into two different files. That also works. Another very similar thing is the animations. So React Native doesn't support web animations and React doesn't support the React animated library that well, at least. You can go around this using React Spring which is a cross platform animation library. We did this in one project. It worked relatively well. So it's possible. I didn't have time to show it to you. But you can find it in the repository. And then, of course, the last bit is the problem mismatch. So in some cases, like the on click, on press, you have the same exact prop basically. But they have different names. So you have to do this platform specific detection that okay, which one we are now and which kind of prop should we assign this function, for example. But in my opinion, those bad things, so to say, aren't that bad. So this kind of approach could actually be something I would highly suggest you to try in your project if you need to support both React and React Native platforms. One thing I want to mention about the component library in the project files, you can actually find a script to how to package this into an npm package so it strips out the platform specific code from the different distributions of the library so that you don't accidentally end up using React Native code or bundling that together with your React web app. But hey, yeah, that's all I have. Hopefully you've learned something new. And hopefully I got you interested in trying out this platform specific code approach. And that's all I have. Thank you. And I'll see you next time.


Perttu Lähteenlahti

Taking Component Driven One Step Further

♪♪ Taking component-driven one step further. Hey, everyone. My name is Debbie O'Brien. I am Head Developer Advocate at Bit. I'm also a GitHub star, a Microsoft MVP, Google Developer Expert, and Media Developer Expert. And you can follow me on Twitter at debs underscore O'Brien. So let's get started. How it's going? And oops, I completely stole Matt Billman, the CEO of Netlify. I stole his slides from his keynote talk. Sorry, Matt. What he said is, how it's going. Number one, he said monoliths are moving to APIs. Number two, Git has transformed the web. Number three, components. Number four, pre-building in JS. And what I want you to focus on is number three, thinking in components. And as he said, the world is moving towards a component-driven world. We're moving towards a component-driven web, and we really need to all be thinking and working in components. Now, you might already be saying, but I'm building in React, and you're totally right. React was built for component-driven development. React was built for components. And basically, what we're doing is, we're building in components. So yes, if you're already building in React, you're doing a great job. We are now building component-driven development applications with React. Cool. So what's the problem? This is our application. It's amazing. This is my beautiful shoe store, and I have made this application out of components. So that button component is actually only one component that's reused inside that hero component in the theme toggler at the top and also in the product card. So we're building in components, and this is how we are building nowadays. And this is great. This is fantastic. The problem is that the components have no value outside the app. So once I've built that application, all those components, they're kind of stuck inside that application. Now, that's a problem. That's not really making component first. You know what happens when we have to build multiple applications? Along comes the product manager, says, we need to build another app. What do we do now? We've got this amazing application and all these components. What do we do? So we've got now three applications, and a lot of these components are similar. We're building similar e-commerce applications. So we've got big components like that shopping cart. How do I rebuild that whole component again and again? I mean, yeah, just a simple button, copy, paste it, put it in there, be fine. Or will it? There'll be inconsistency across all your applications eventually, especially if you scale and grow and grow and grow. So really, you need another solution. You basically want to be able to easily share those components across those applications. And there are a couple of options out there, of course. And you could just basically package them up to NPM and hope for the best. I mean, there's a lot of work involved in that. It is possible, but it's painful. And we don't want pain, right? So there's a couple of options, as I said. And one of them is to work in monorepos. Now, a lot of people do this. A lot of people are very happy working in monorepos because it allows you to scale those applications, put loads of applications inside the one repo. And when you do that, you can improve velocity. So you can just build more and more applications really easily because you have access to all the code from each of those applications. That means you can do code sharing really easily and reuse any of those components in any of the applications. So the dev experience is actually pretty good, right, because you have access to everything. So it's easy for you to just, you know, build stuff from anything that's in that repo. And if you have to refactor any of those components, well, it's kind of pretty easy, too, because, like I said, you've got access to them. And cross-team collaboration, you're working with all the team members on this. So, you know, it's pretty good. And you've got some standardization going on because you've just got one repo to maintain. So everything's running on the same standardization. So this is a good point. Unfortunately, with monorepos, there are a couple of issues. The tooling wasn't built for monorepos, so the tooling really isn't there. Your IDE can get slow because you've got so much code to load. And, you know, you've got, like, git pull, git push. Again, it's going to be quite slow because you've got so much to pull down. When your teams are getting bigger and bigger and bigger and more people are making changes to that main branch, you've got all those, like, merge conflicts to deal with, and you're constantly, like, bringing those new changes in. Visibility and discoverability, this can kind of go both ways, right? Because you could say, oh, in a monorepo, I can actually see all those components that are available to me. And you can. You can see all the code. But you can't really see what the component looks like. You'd have to, like, which app is it being used in, and you'd have to try and find that application to see what it looks like to try and kind of really discover and visualize it. And you've got, like, to make gradual API changes because if you start modifying the API, you don't even know what component is using that API. So that component is being used by another one. Is it being used by what application? So it's really hard for you to see where it's being used. And are you going to break someone else by just, like, modifying the props, modifying the API of that component? Probably. That's not good. Onboarding developers can be, you know, pretty hard. You get a new developer in, and you give them this massive code base and say, good luck, go swimming, find the code, figure it out. You know, what if you could just separate it out so that one new developer just has to worry about the code that they have to worry about? That'd be much better, right? And the feedback loop, it can go on for quite a while because it's got to go through such a process. And when it finally makes it to production after everyone else has finished building what they're building and maybe you deploy at this time at a specific day, you know, once it gets deployed, so there's a long wait time when really you just want to, you know, make one change and just deploy it, right? Why can't we do that? Team boundaries and ownership. I mean, there are no boundaries, right? Everyone's working in the one code base. I mean, you could say, don't touch that folder that belongs to that team, but that's kind of, like, pretty hard, right? There's no policing that. So there is no real boundaries. And your build times can be pretty big because you've got to build not just that one application, but every single application in that monorepo and all those components. So, you know, do people actually like working with monorepos? Do they hate them? Do they love them? This is what I asked. And you know what? The problem is actually the tooling. The problem isn't the monorepo. Monorepos is a great way of thinking of doing stuff, but the tooling just hasn't helped, as Oliver says, or Garrett says, crappy tooling. Even Brandon, he's like, loves the fact that you can share code between apps and libraries, visibility, collaboration, consistency, ability to standardize single package versions, but he hates the insufficient tooling. This is what makes the experience bad, leads to bloated CI, and just loads of ad hoc scripts. So how can we fix this? How can we make this better? You know, what do people want? That's what we got to look at. What problem are we trying to solve here? What people want is the ability to share components. They want to be able to easily package, manage their components. They don't want to have any version conflicts or break each other. They want to have quicker build times. They want to just build what they're building and like have that released and not have to worry about what everyone else is doing. They want team boundaries and ownership. So they want to own their own feature, their own components, and like just work on those and leave everything else as if it like doesn't exist. And they want consistent tooling. They want all those components to be built with a similar kind of tooling so that they're all going to, you know, build as they should be built and look the same across all those applications. And they kind of really, really want simple decoupled code bases. So they only have to worry about the code that they're actually going to have to worry about. So we're not asking for a lot, are we? Well, actually, welcome to Bit. Bit is a tool for component-driven development. And with Bit, a lot of these problems are solved because of how Bit allows you to work with components. If you want to work in a monorepo, you can work in a monorepo with Bit. You can simply have your base UI components, e-commerce components, and your store components, your application components, all in the one monorepo. The difference is that every component is completely isolated and versioned. And therefore it's like its own little kind of repo, I guess. Every component is isolated, which means it can be used in any of those applications or any of those other libraries. Now you can also have a simple decoupled code base. So you can literally say, okay, I'm going to separate it out because you know you're scaling, team's getting bigger, and you want teams to own features. So you can have one team, base UI, this is your repo, and these are your components. You're in charge of this and build your components and deploy your components when you want to. E-commerce team, here's your components, build your components, deploy your components, and just work wherever and whenever you want to. And then your applications, there could be another team that own the specific applications and they can deploy their components and their application whenever they want to. As Bit versions each component and isolates each component, it can then be used in any of those repos, installed into any of those, and basically used across any repo. So here's an example. This is my base UI code base and VS code. And you can see on line two, I'm importing the button as a component from this actual repo, right? From the base UI repo. So it's importing it instead of using a local import because every component is version and isolated. I need to basically install it as if it's its own package. So I'm installing this button and using it inside this team toggler component. Now my e-commerce team, I'm installing the button as a component. And I'm using it inside of my team to install the button as a component. Now my e-commerce application, or actually this is not an application, it's just a load of e-commerce components. But in this e-commerce repo, I'm actually installing that same button component. So here I'm installing the base UI from the base UI repo, the button, the card, the heading, and a few others are coming from a different repo, the one I just showed you. And it's also installing some components from this particular repo, from the e-commerce repo. So I'm installing the button component and I'm installing the button component. And I'm installing the button component and I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. And I'm installing the button component. So, here we've got our product card and we have the latest version. It's version 1.0.13. And basically we can go back in time at any moment. And we can see the state of that component. 1 back or 10 back or 0, 0, whatever. And we can see what it would look like, what has changed. And we can decide what version of the component we want to use. Now, if we're working in a workspace and we were to modify the price component, for example, of the product card. Then the product card will get auto-tagged and a new version will auto be created. Because the price component that it depends on got modified. Now, if you're working in another application, in another wrapper, and that product card gets a new version. You're not going to break your app or anything. Because you get to decide if you want to use the latest version or not. Basically, it will tell you there's a new version. Do you want to import the new version? And you can say, actually, no, I'm not ready to update this version. Because you haven't finished updating the rest of the application to the new theming or etc., etc. So, you always get to choose which version you want, when you want to update. And you can have multiple versions, different versions across different applications, if that's what you want. And you can see what's going on at all times. So, you can look at your component and you can see this product card component is using version 2.0.1 of the button. And you can see it's using the card, the heading, the image, the text, the available colors, and the currency component. And which version all of them are on. So, at all times, you can actually visualize the dependency graph of your component. So, basically, we want to reuse components in any app. This is what we're trying to achieve. We want to take the components out of the app. And we want to make the components isolated. We want to make the components their own specific, like, they want to basically say, you're a component and you live wherever you want. At the moment, you're going to live in the base UI repo, in the e-commerce repo, whatever. But that's not important. What's important is that you are isolated and versioned independently. You can be released independently. And you can be installed into any application, any other component, whatever. You can be used at all times very, very easily. And this is what you want. You want to make the component number one. This is what we call component-driven. And this is basically what we all should be doing. We should be building component-driven webs, component-driven apps, component-driven everything. And building with Bit is going to make that easier. So, I highly encourage you to check out Bit, give it a try, and start thinking in components, building in components, and building a better web. Thank you very much, everyone. If you want to see the Bit demos that I walked through in the shoe store, et cetera, you can just go to bit.dev slash learn-bit.react. And you'll be able to see all those that I just showed you. Or you can just go to github.com slash bit-demos. And you'll see all those individual repos. And you'll see how the components are being used across all those repos. Check out our docs for more information. There's videos and there's all sorts of stuff on there. And, of course, you can follow me on Twitter, devs underscore o'brien. If you have any questions at all, if you want to play with Bit a bit more, and you've got some feedback for us, DMs are always open. So, yeah, have fun building components, building React applications, and making the components number one. And the components are just going to be used within all those applications wherever, as many as they want, wherever they are. And that's it. Thank you very much. Bye. ♪♪♪


Debbie O'Brien

Components, Patterns and sh*t it’s Hard to Deal with

Marco Cedaro

React Summit 2020

Introducing React View

♪ Hello, my name is Vojtech Miksu and today I am going to talk about documentation. My job is building React component library called BaseWeb and other web tools at Uber. BaseWeb is an implementation of our design system and we use it across all applications. So let's talk about documentation. It's something that most of us use every single day and it's absolutely essential. Every day we are sitting at our desks trying to learn things by reading and only sometimes we pause to write a few lines of code. And there are many different sources of documentation. We have books, MDN, Stack Overflow, comments in the code, or we just randomly Google things until we give up and slack our colleagues. But what is my real motivation to talk about this today? I joined the company two years ago and this was the proposition given to me. Join us, you'll be building React components. It sounded amazing and I was immediately sold. However, the reality of platform-oriented work is slightly different. It looks more like this chart. And frankly, it's a good thing. If nobody uses your things, it means if nobody asks you questions, it means nobody uses your stuff and it would be awful. So you could say my team became a victim of its own success. When we started BaseWeb two years ago, it was barely used and we had a lot of time to just write code. But then the usage spiked. There's now over 600 applications just in Uber. And that translates into almost like 1,000 developers. Also our library has a giant API surface. There are over 60 components, hundreds of props, and pretty much endless possibilities. We also have a lot of outside contributors and users. So naturally, we spend a lot of time with support. The question was, can we reclaim some of this time back? I strongly believe that if we build an amazing documentation, we can significantly reduce the number of questions in our chats and GitHub issues. Also we do frequent surveys. And documentation is always the most mentioned topic. So my team now invests a lot of time into experimenting with different kinds of documentation. Hopefully by now I made my case for why documentation is so important. Here's the agenda for the talk. I'll show you some older versions of our documentation website and explain why it wasn't good enough. Then what we built with React Vue and use today. I'm also going to peek under the hood and show you some concepts and code related to compilers and abstract syntax trees. And finally, conclusion. So this is the oldest version of our documentation. It's just storybook. It's off the shelf solution. We used it to develop our components, but also to document them. You can see it's pretty much a bunch of examples. And at the bottom, you can see readme, where we document our props. But as we grew the number of components, we wanted to have something more structured and customized. So we launched our own custom website based on Next.js and MDX. Now components are in different categories. The page itself is more structured. Each example has its own source code that's manually written. And at the bottom, we have prop documentation generated based on static types. And this works reasonably well. Until it just doesn't. Some static types are just too complicated and not really human readable. So many props are meant to be used internally only when composed by other components. But now we expose them in the public API. And that's just confusing. We tried to tweak this many, many times, but it was never reliable and not sufficient as the primary source of documentation. Developers can always tell when something is auto generated, and they will not exactly love it. Why should they put extra effort into reading it if you put zero effort into creating it? So how about adding a lot of examples? Who doesn't like more examples? This is our tech component. It's pretty simple. And yet there are 384 different permutations of it. Can we display 384 examples on a single page? Sure. Is it going to be overwhelming? Absolutely. And the same thing goes for other components. If there's a limited number of examples we can present to not overwhelm our users, what else we can do? Well, let them toggle and explore these permutations. Let me show what we built. So this is like a playground we built for our components. First of all, you want to display the component itself. Second most important part is probably the source code itself. The nice thing about the source code is you can edit it in real time. And as you type, it changes the component. If you make a syntax error, we just tell you what's wrong. We also added this feature where you can hover over different components and see their static types. So this is a pretty common feature on a lot of documentations. But have you ever asked how this actually works in your browser? There's a useful API for creating JavaScript functions from strings. The first argument are parameters of the new function followed by the body. Unlike a val function, this is executed with a global scope only. So anything you want to pass and use in this function, you need to pass as an argument. So now we can dynamically execute any JavaScript from string. But what if we don't deal only with plain JavaScript? And actually, we almost never do. All of our components use JSX. And you probably saw what happens if you try to run JSX in your browser. You get the syntax error about unexpected token. We can't really ask people to type React great element instead of JSX. So we need to introduce some extra step, some extra process. We need to add a compiler. Remember Babel? Most of us use it when we need to compile our applications. But we can also use it in our browser to compile our JSX into React great element. We use transform function from Babel core. We load up React preset. We pass it our component. And it returns the React great element call instead. So this works pretty good. So now we have the component. We have interactive source code. Let me also edit some convenient functions. For example, developers like to format their code so it's more readable before they copy paste it. You can copy the code into clipboard. You can get a permanent link. You can get back into the initial state. And you can also spin up code sandbox and do more serious editing if you wish. So this is great. But sometimes you don't even know what other props you can use for this component. So you need some sort of props API or props documentation. So we added this additional part we call naps. So each prop is represented by a single nap. And you can also interact with it. So as I change this value, you can see it updates the component itself. But most importantly, it also updates the source code. So this state is synchronized across all these three parts. And it gets even better. For example, if I change this kind to secondary, you can see it even changed the import. So this is like something you can always copy paste into your application and you get this exact component in this exact state. So not only I can interact with these snaps, I can also still change the source code itself. And you can see, again, it updates the state here. So this checkbox is now checked. And the component is in loading state. So how does this work? First of all, we need to somehow describe what properties our button has. So we can render the naps. We've created a simple configuration format. Here's the example. For each props, you can set name, the type, and description. And when we update the code, we now somehow need to extract some pieces of information out of it. Including the prop names and values so we can display them in our naps. The first quick solution would be to use a regular expression like here. Here we are matching JSX element and getting back the parts with props and children. It works. But it's extremely brittle. What if we have multiple components? What if they are nested? How to tell them each apart? Now the code is just a dumb one long string. We don't have some deeper understanding what it really represents. So we can't really do much about it. We need a completely different and more powerful approach. We need to turn our code into a tree. The abstract syntax tree. Fortunately, we already have a tool just for that in our project. It's Babel. In order for Babel to do anything with your code, it also needs this deeper insight into its meaning. So it always starts by creating an AST out of code you pass to it. You can inspect ASTs in this very useful tool called AST Explorer. So here's our button. We are using Babel parser. And on the right side, you can see the tree representation of our code. Now if I hover over different parts of our code, you can see what node is being highlighted. So for example, this button now corresponds to this JSX identifier. If I go over the type, you can see it's a JSX attribute. And the primary is a string literal. So now I know exactly what each part of this code is. And I can just be sure I'm getting values I need to get. So here's the implementation. Like first you use the parse function from Babel parser. And you give it your code. And this actually generates the tree structure you saw. And then we use traverse function to walk this tree. And we are looking for all JSX attributes or props. And once we get this type of node, we just save the name and the value. So this is like very simple way how we can get all the prop names and values from our component. I also demonstrated we can do it in reverse. So I was able to change these snaps. And it was actually updating this code. And by the way, we've never written a single line of this code in our examples. This is all generated just based on the prop configuration and the state of this playground. So how this process works in reverse? How do we actually generate a code? So as you can imagine, there is some sort of state with props where you have the list of the names and its values. You know what the name of component is. So again, we could try something simple. And we could just glue a bunch of strings together. And this will give us the final snippet. And it works. But again, it gets complicated pretty quickly with all the exceptions and different cases. And it's also a very easy way how to produce a code that doesn't work and has some syntax errors. We already learned similar lesson with regular expressions. And so again, we need a more reliable approach. I mentioned trees already. And it turns out we can also just build them from scratch. So this is a simplified example of function that creates an AST of JSX element. We can compose nodes together to build our own tree from nothing. Since all these functions are statically typed, if we are forgetting to pass any value, we will get an error. And now we can be sure that whatever the final script is, it's going to work. So this is of course now we have the AST, but we still need to turn it into the code. So once we have the AST, we can use generate function from Babel generator. And this just turns the AST into code. But there's one glitch. This will result only into single line of the code, which is not super readable. So we can get fancier and we can use other popular tool called Prettier. And Prettier is actually using the same AST representation for the code as Babel. So we can just use Prettier to print out much nicer code snippet. So there are many other features of this playground I don't have time to show you. For example, not all components are as simple as button. Sometimes you need to include multiple, sometimes you need to use local states to make your examples realistic. We support that. Sometimes you need to nest multiple components. We support that. Or you even want to build a custom prototype and a custom knob for it. We also support that. All this is prepped in this library called React view. It's open source and it has its own interactive documentation. So please check it out. And here are some final thoughts. First, documentation is immensely important and a critical part of anything you ship. It helps your customers to use your product. But do it also for your own selfish reasons. You can save yourself a lot of time by not answering questions that can be answered by quality documentation. Second, how can we make documentation much better? Get your superpowers with abstract syntax trees and tools like Babel and Prettier. We already use them to build our applications. But we can also use them to write some boring parts of our code and build much better documentation. And finally, to get started, check out React view. It's open source and it covers all examples in my talk and our documentation. And there's one more thing. We found another use for having a prep specification for each component. We translate it into VS code snippets. It's a great power user feature. Oftentimes your developers don't even need to read documentation to produce new code. And what's better than that? If you want to keep up to date, here's my Twitter. And thank you for watching. Fantastic talks today. And yours definitely added to the long list of great talks that we've seen. And again, I just... The quote. Ah, so good. This is like... Yes, documentation matters, people. One question that I was thinking about when I saw this, and I remembered how I started with documentation back in the day. How would you say... What is a good way for people to get going with creating documentation? What's the good starting point? Yeah. So for us, it was also like a process, right? It took us a while to just build the whole thing. So I would say start incrementally. I think Storybook is a great option, because you can use it to develop your components, and it has some really cool add-ons, so you can also document them. And then after a while, when that's not enough, or you feel you need something more, maybe you should use a custom-based solution. We had a really nice talk about Gatsby and MDX. I really, really like MDX. We use it as well. We use Next.js. It's similar. It's a little bit faster. But yeah, just start incrementally. Storybook is a great way how to get started quickly. MDX is amazing after. That actually brings me to a question from Fosu from the channel, which is, if I do have a Storybook showcase library, should I try out ReactVue for the documentation? Our design system is pretty integrated with NX and Storybook. Is it a complement or an alternative to Storybook to use ReactVue? You can use it with Storybook as well. ReactVue is just a React component, so it can be used in Storybook. In some ways, it's similar. In Storybook, you also have these snaps where you can change values and just see different variants of your components. ReactVue goes a step further. It generates the source code for you. So yeah, you can use it at the same time. Storybook supports anything. You can just put there any React component. ReactVue is just another React component, so you can definitely use it together. That is nice. That is pretty cool. And you mentioned, coming back to the original question on how to get started, you mentioned that it was a process for your company. So what would you say was the process like? What were the steps that you had to go through besides picking your technology and picking a solution to produce the documentation? What did the full process more or less look like? Right. So first, we just started building the whole component library. That was the priority, just to get all the components out. So that's why we used Storybook. So we didn't spend that much time on building custom documentation. But then we also have this support channel, and we were listening to people. They have a lot of struggles with using our components. And we were always trying to answer these questions. And then we see people are asking the same type of questions. We were thinking, OK, how we could bring these questions together and just solve them in our documentation so people stop asking us the same thing again and again. So try to ask people that use your documentation, your project, what they think about your documentation, what is missing. They will definitely tell you, because they spend a lot of time just searching for answers. So it's kind of like this constant feedback from your users that actually keeps improving your documentation. So you should frequently ask them, maybe do a survey. Yeah. That is really cool. Also, I was wondering about this. I guess you built the component library, and I'm pretty sure that you have lots of components, right? And not just that. The components are one thing that people might have questions about, but there might be auxiliary questions or frequent questions that you get asked that are not necessarily straight related to one component, but the interaction of components or something like that. How can you make sure that users find the answers to their question within your large body of documentation? Yeah, that's a great question. So that was also one of the reasons why we decided to build a custom documentation, not just using Storybook, because it's not enough just to document components, but you also want to have the story around the whole system that just covers some other big questions. So also one thing how to make this easier is having a good search in your documentation, having a good full-text search is really nice. And there are some open source free solutions like Algolia, which are really nice to just build the index for you. Nice. Yeah. That's pretty cool. And I think there's also what's it called, Solar and there's another one that I can't ... Elasticsearch. No, that's a different thing. Elastic. Is Elastic a full-text search? Elasticsearch is more for... yeah. Yeah. So that would work as well. I haven't actually tried Algolia much. Also, excuse me. Also, another thing that I've seen is that you can actually just use a simple search and then you can just go to the search and then you can just search for the topic. So that's a really nice thing. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.


Vojtech Miksu

Why Paid UI Components Aren’t Evil

♪ Hey everyone, today I'm going to talk to you about why paid UI components are not evil. And the reason I want to give this talk is that almost all the software that we use on the front end today, so think about React and all the different React tools and components that we use, they're basically all free. Which is kind of awesome, actually, mostly because it greatly lowers the barrier for newcomers to get started in the industry. Back when I was getting started on software, and also apparently nine feet tall, I wanted to use what the cool kids at the time were using, which were tools like Flash and Java. But the problem is, these things cost money, and poor high school, college TJ couldn't afford them, so instead I moved over to the web, because the tooling there was something that was completely free. And really, this is how my career got started, and the reason that I'm here today. I went on to work for the jQuery project, I spent two years working on jQuery UI, so if you were building apps with jQuery UI ten-ish years ago, you might have used components and controls that I helped build and maintain. For the last few years, though, I worked for a company called Progress, and on a UI component suite called Kendo React. And importantly for this talk, we charge money for the controls that we make. And having worked now on both sides of the equation, for both free and paid UI components, it's given me a whole different perspective. For example, you might assume that our biggest competitors for Kendo React would be other paid UI component suites. But actually, what we find is we mostly fight against developers' sort of expectations, especially frontend and React developers, that all controls and all software for this world are free. So you'll see things like free in search terms, and on lists of components and such in recommendations. So today, I want to give you four reasons to at least consider paid UI components. And this is a lightning talk, so we're going to make these four lightning reasons and go through these kind of quickly. So the first reason is guaranteed support. With free UI controls, the help that you receive is largely dependent on how willing the community is to devote their time, which sometimes can work out great. But other times, it can mean you're digging through long stack overflow threads or huge GitHub issue lists to try to find help that you need. With paid UI components, one thing you often get is some form of guaranteed support. So for example, with all Kendo React licenses, you get dedicated 24-hour response times. Essentially, you have an issue, you create a ticket with us, we're guaranteed to get back with you and help you out within 24 hours. Reason number two is long-term peace of mind. So another problem with free UI tools is that there's no real incentive for the authors to continue working on their project after their sort of initial motivation to create the thing occurs. And because of this, there is no shortage of sort of projects that haven't been touched in a long time on GitHub and throughout the web. And to be clear, I'm not blaming the authors for this in any way. After all, they're putting their work out there for free. But rather, as sort of Ben Lesch, who's the author of RxJS said, anyone that thinks they want to be the owner of a popular open source project is a fool, which is something I can commiserate with from my time on jQuery. I got a lot of benefit out of working on the jQuery project, but I also had to deal with some of the worst of the worst on the internet from people that wanted to know why their date picker didn't work in their super complex application. When you pay for software, you have a direct financial relationship that isn't so dependent on the author's goodwill and motivation. And that makes the project much more likely to stick around. So for example, with Kendo UI, we launched back in 2011. And if you used our series of jQuery plugins on day one, those are jQuery plugins that we're actually still maintaining in 2020. We're actually still adding features to those components as well. So we've been around for the long run. Reason number three is paid UI components often solve harder problems. There are a lot of developers out there trying to make the world's best React date picker. And you can find lots of great free ones out there. There are fewer developers out there trying to create the world's best React Gantt chart, which is something that we ship as part of Kendo React. Or the best scheduler, basically creating an Outlook calendar in your browser, which is also something we ship as part of Kendo React as well. Paid UI components also tend to ship features and guarantees that aren't necessarily a given with free controls. So for example, on Kendo React, we spend a lot of time making sure all of our components adhere to numerous accessibility standards and provide globalization support. Which again, with free controls can be hit or miss, especially if you're trying to piece together a number of different free controls and make them work well together. And finally, last on my list is with paid UI controls, you get more of the same funding model. And I include this because in our front end world today, the value of this software that we use, so again, think of the different React tools and components that you use in your day to day job, is in no way equal to the actual amount of financial value that these developers are actually compensated with. Which has some frankly kind of bizarre consequences. For example, we now see things like NPM install logs containing advertisements, which is something that somebody tried to do. And if you write React, you've probably seen a CoreJS person asking for jobs, which is something that happens as well. There's a sort of weird set of foundations out there with some very nebulous funding models. There are things like Patreon and GitHub sponsors, which are things you probably feel like you should contribute to for some tools you use, but you probably also aren't either. When you pay for software, you don't have to worry about how the developers behind the software are getting paid, because the relationship is way more direct. For example, at Kendo React, we make a suite of 80 plus React UI components, and you pay us money if you want to use them. There's no weird sponsorship or donation model. Now, to be clear, I'm not saying that paid UI components are a panacea. We're not going to solve every problem that you have for your applications. Instead, I'd encourage you to do just a bit of a time benefit analysis, because front-end developers' time isn't cheap. And there are some real costs and time savings to be had from having things like guaranteed support, from knowing you're going to hear back on issues that you have within 24 hours, from having a bit more long-term peace of mind that the code and the tools you use are going to be around for two, three, five years to come, from solving harder problems, from knowing things like accessibility is something that's going to be taken care of for you, and from having that more direct financial relationship with the authors of the tools that you build. So the next time a new app comes up, you're starting a new project, a new initiative, I'd encourage you to at least consider paid UI solutions. Have us on the list of things that you're going to test out. And if you're interested in trying Kendo React, you can learn more about kendoreact.com. And if you have any questions, you can ask them to me throughout this event. And I'm also at TGVentHole on Twitter. So thanks.


TJ VanToll

JSNation Live

JSNation Live 2021

Building a Custom Component Library – Fast

Hey everybody, I'm TJ and today I want to talk to you about building custom component libraries fast. And by component libraries, I essentially mean a series of UI controls that can be anything from buttons and inputs to more complex things like date pickers and autocompletes. Now me personally, I've been building component libraries like this for a long time, maybe too long. Back in the day, I was a member of the jQuery UI team, if you remember that. I still have this sweet hat to show for it. And more recently, I'm now a member of the Kendo UI team. And because I've been doing this for many years, I've developed a series of opinions or hot takes about component libraries that I'm going to start by sharing because I think you'll find them interesting and also useful. And then I'll move on from that to show how you can put these things into action and give you some recommendations on how you can build your own component library. So to start, my first sort of opinion or hot take is that I think every company, I think your company should have its own standard set of UI controls. And the reason for this is really consistency. So you apply some visual consistency so that instead of having 30 different button designs, you create a button and a component library that sort of has the one true way of building buttons for your organization. But you also get consistency in terms of things like technologies. A component library is sort of a forcing function to help you choose a limited set of texts that you want to push out and sort of promote throughout your organization. You also get consistency in terms of accessibility. Accessibility can be hard, but if you can get it right within the components within your library, you can sort of then spread those accessibility benefits to other parts of your organization. So I think every company should have its own UI component library. And I also think that companies shouldn't build the harder parts of those libraries themselves. And by complex components here, I'm not talking things like inputs and buttons. I'm talking about the harder stuff, the date pickers, combo boxes, autocompletes, data grids, things like that, because these components are harder than they might first seem. So take the date picker, for example. You don't just have to build a calendar here. When you're building a reusable component, you have to take into account all sorts of other things. How are you going to make this accessible? How are you going to make sure it works like you expect on mobile? That TypeScript works? That you're going to document all this so other people understand what you did and that it's extensible and all of these things? And these are solvable problems. You watching this, I can see it through the camera. You are a smart person. These are problems you can solve. But you as a software developer, also, your time is very valuable. Your time is almost always better spent on things that are unique to whatever it is your business is doing than reinventing the wheel and solving some of these UI component problems that have been solved by a lot of libraries for a long period of time. It's just a better use of your time. So I think companies should have their own component libraries. I think you should not build the harder parts of these libraries yourself. And I also think that you should lean towards using components that are specific for a framework that you like to use, like a framework like Angular, Vue, and React, than a framework that's sort of framework agnostic and tries to work across the board. Now, this is a hot take that I share with Brandon Dale, an ex-member of the React team. And I think he phrased his explanation more elegantly. So I just stole a quote from him. And he says that compatibility always comes at a cost. And that cost is always going to be something like performance or bundle size or framework ergonomics. And in the majority of cases, those things are going to be more important than the compatibility itself. Now, this is something we believe quite strongly on the Kendo UI team. So strongly, in fact, that we've built four separate component libraries for different frameworks. And we do this because, as you might imagine, it's quite a bit of work because our users consistently tell us that they are more successful, they are more productive when they use components that are built for their framework of choice specifically. So I think companies should have their own standard set of UI components. I think they shouldn't build the harder parts of that themselves. And I think that in most cases, you should lean towards using components that are built for your framework, for your tool chain of choice. So how do you take these things and put them into action? Well, I recommend starting by just setting up a development environment that you can use to build components in a place that lives outside any of your existing apps. So what I like doing is I like to have an environment where I can both develop on the components and then also have a demo application where I can then test those components in a live running app and see how they work. And then also having a few scripts that let me take my components when I'm all set with them, sort of package them up, bundle them up and distribute them so that they can be used throughout my organization. And I'll give a link if you're interested in this at the end of this talk so that if you want to see my preferred workflow in detail, you can walk through that. But just start by having this development environment. And from there, I would then recommend having a go-to library that you're going to reach to for some of these more complex widgets or really anything that you don't want to build yourself. And for that, I would look for a handful of things in this sort of third party library. I would start by looking for comprehensiveness. You don't want to be pulling components from five different places throughout the Internet and trying to make them together. You'd have one library that provides as much of this as possible. You want to look for accessibility because, again, you want to bake in good accessibility to your components by default. You want to look for framework specific components or at the very least something that works really well with the tool chain that you like using. And you also want to look for extensibility. The thing about a component library is that people are going to find ways of using your components in a lot of different ways. So you want to find third party components that are very adaptable, that you can sort of tweak and theme and change things about every little piece of them. So I'd recommend having this third party, this go-to third party library. And then I'd recommend creating wrappers of any of the components that you want to use from these third party components. And the reason for that, and we'll just show an example, say you want to use the Kendo React Datepicker. Well, instead of encouraging developers to use the Kendo React Datepicker API directly, instead in your component library, you could create a wrapper of that Datepicker with your own API. And the reason for this is, again, back to enforcing consistency. Because you have this wrapper, you now have a place that you can consistently implement things for Datepickers throughout your organization. So say your designers come back and say, hey, we need all our Datepickers. We need a small little visual tweak. We can be like, oh, hey, I have this wrapper. I can consistently apply this class name. I can make some CSS tweaks. And I still have this control where I can consistently make changes to this component throughout my organization, while still now having to build the hard part of these components themselves. So to wrap up, again, I'd recommend starting by just setting up a development environment, make it outside of your existing applications. From there, I choose a go-to library for building or for bringing in third party, more complex components. And then I create wrappers of these third party components that you bring in. And really, if you take just one thing out of this talk, in general, I would say your company should have a standard set of UI components. There are just a ton of benefits. But it's totally okay, perhaps even preferable, to build a lot of that functionality on top of an existing library. So hopefully you found this interesting. If you did, if you want to learn anything more, you can head to bit.ly slash components dash fast. There, I have the full development environment that I talked about in an earlier slide, as well as some articles that walk through the arguments I made here today in quite a bit more detail. So my name is TJ Ventole. Feel free if you want to reach out on Twitter to ask any other questions or ask any questions through the conference as well. Thanks.


#component library