Video details

Katerina Skroumpelou - Build a design system with Angular + Nx + Storybook | Angular UP 2021

Angular
03.21.2022
English

Build a design system with Angular + Nx + Storybook If you are part of a large organization or team, chances are you need a design system. There are tons of tools out there to help you develop and organize that design system, but in this article we will see how a combination of React, Nx and Storybook will make that process more efficient, more enjoyable, and definitely more scalable. Katerina Skroumpelou - JavaScript Engineer, Narwhal Technologies, Inc "Software Engineer at Nrwl, Nx core team, GDE for Angular/Web Technologies/Google Maps platform, AngularAthens meetup and RevApp co-founder. Mentoring women into tech, speaking about the cool things I do, climbing mountains and serving cats for life. More at psyber.city. "

Transcript

Hi, everyone. Thank you very much, Angela, for inviting me. I'm so sorry that I could not be there in person. It was used to me. I was a bit worried because I hadn't gotten my first, like, screenshots and all this Coronavirus thing that's making things so complicated. I really hope that in the next version of Angular app, I get to be there in person if I submit a talk and you want me there. So I really like the fact that I can see the audience. It's been so long since I gave a talk and I could see the actual audience and see the feedback of the people. So that sounds cool. Let me start sharing my screen. Wait, let me move to my other screen and I'll start the presentation. No, I'll start sharing my screen first. Share screen and I'll share desktop one. Can you all see my screen and my presentation? Yes. Okay. I see the thumbs up in the audience. That's great. Okay, so today we'll talk about how to build a design system with Angular, of course, MX and Starbucks. So I'm Karina. I'm a core member of the MX team. I'm also a Google developer expert for Angular, Google Maps, and web technologies. I'm also the Android Athens Meetup co founder. I'm also a speaker, an instructor, and a cat person. And also this is me on top of Mount Olympus because I also prime mountains. And you can follow me on Twitter at Cyber City or find all the information you need at my website, Cyber City. And if I like if during the presentation, one of my caps will come here and be with it. So the agenda for today is we're going to explain some core concepts. What is a design system? Which many of you may know, but we'll do a brief overview. We'll see what storybook is. We'll see what NX is and why Marlon would want to use Annex and Storybook to build design systems. And also we'll see some demos around generators, migrators, the NX console, and a small conclusion in the end, of course. So let's see first, what really is a design system? Broke Frost has this great definition that I like. A design system is the official story of how your organization designs and builds digital products. Essentially, it's a set of styles, rules and reusable components that an organization or an application uses. So you may think that it's like a catalog of UI elements almost. I would say that. Think of material design. I'm sure that if not all of you, most of you have brought through the material design of Google, right. And there you will find some rules about the spaces and the shadows and whatever else. And you will find some ready made components like buttons, links, which you can reuse. So this is the design system, right? So think of it like that. Let's see what Starbucks is now. What is Starbucks? It's an open source tool for developing UI components in isolation. What does that mean though? Let's think of a scenario. First of all, before I go interact with services, think that you're creating a very complex website with registration, that users have a form that they have to register their data and they also have to put their credit card data inside. Think of a very long form with many steps and validations and complex validations and everything. And you want to see if you're developing this form and maybe it's a bit complicated to test it. And you want to change the styles of a specific button or a specific toggle on the third page of that validation form. After the user has put in their data, they have put in their address, they have put in their credit card details, and each step they have to validate, of course, and make sure that they discredit. And you want to change the styles of the toggle on the first page of that form. So normally you would have to go through the flow or you would either have to write some of data or some way to bypass the validation this time if you wanted to test it locally, or you would have to go to the validation time, or you would have to go to do some extra work in order to be able to go straight to the third page whenever you refresh to change the size of the Toggle. Right. And as I think of it as a headache, what if you could take this toggle out of there, have it somewhere differently in some other space, and only serve this toggle locally, where you can change the styles and adjust the style each time in order to see how it changes? Log Starbuck does exactly this. It lets you develop a component in isolation. It lets you take the toggle and serve it separately locally in a separate page. And you can change the styles and adjust some fields and see the styles changing instantly, for example. And we'll see what I mean. So what it does, it lets you create a story for a component. A story is actually a definition of what you want your component to show. So if you had a Toggle, your toggle story would be another toggle to be enabled to be of color red. And when you change it to turn green, for example, it makes you create a scenario, use the components in a story describing use case scenarios like the one I sent, various States of a component. So a different scenario would be if you wanted to see that all tested, otherwise to be disabled. And when it's disabled, be great for example, and then to share the results. The collection of stories and what it is a storybook which serves like a catalog of the available elements and the state of elements. So a storybook actually is a collection of all the stories of all these different States of the components that you're using. So let's see an example. So this is the Storybook website and in the Storybook website they have a list of Live storybooks. And the great thing is that you can publish the storybook online. So the Storybook application UI has its own storybook that it's running. So if you build a storebook for your app page, let me Zoom in. You will see that you will have a list of all the available components and if you click on one of these let's find something nice. You will see that you can see individual labels, for example that you can change. And here are some fields that you can change which we're going to see especially in the demos. So here is a list of all these things. If we see the buttons, for example you see here, it has a list of all the bottoms and you would be able to change if I had access to it, I would be able to change the colors and fill the buttons differently. But it lets you actually test out the components in isolation like test this button in isolation just like they are with the presentation. So the cool things about Snowball are that you can develop entire UIs without needing to start up a complex test pack. Like remember the example I gave you before in order to set that total in the first page of this registration form you don't have every time start out of your server and start up your whatever to do the validations and everything. You can just develop the entire UI without needing to start everything again. You can just start your storebook and see that in isolation. Also it can serve as a documentation for your UI library or system. Like we saw before how the Storybook design system looks like a Starbucks storybook looks like we could just see the documentation of all they have these buttons and they have these buttons in different States and they have these links and everything. So it can really serve as a handicap. I guess you can easily also browse and trigger different States and you will see what I mean by that in our demo. Also it integrates with most front end frameworks like React Angular which we'll see today. So essentially the syntax does not change much between the different frameworks that it's very handy. Also it integrates with Cyprus for your It tests because I guess when I was explaining the right a different scenario to go through a different path testing a component, I'm sure to most of you it may have sounded like an Itui test. The cool thing is that the fact that it integrates with Cypress lets you reuse your component stories in order to run Cypress and Tweet tests which we will see during the Mxm test we'll see which is very handy because you don't have to write things like you don't have to write your test twice you just write the storybook and some stories with some scenarios and you pass them into Cypress and it uses the stories to test your components. As I said, right next, rely on your stories. So how does it work? The way it works is you just have a story file right next to your component file. You import your component in that story and then you drop out scenarios and I'm sure it feels like an interesting so let's see what it would look like. You just said a story file storage. Yes. Right next to your component file you put your component draft no scenario. If you see for some reason I cannot point with my mouse now. But if you see for example that you have an angular component file in my button component, you see that we have my button TS and above it we have spects HTML, TS and stories. Ts. So you have to add it there. Also if you see at the top of this list there is a storybook folder where inside we have some configurations which are very lightweight and they don't need much. I mean you can just use the out of the box one which we will see what they are. So if my custom button component looks like this, I just have free input. It's a dumb component. I have three inputs, one for the label, one for whether my button is disabled or not, and one for the background color. And my template accordingly would look like this. It would take a disabled value, it would take an Ng style for the background color and it would also take the label. What would our story look like? Our story would look like this. You would export your my bottom component which you have imported and then you will create a template instead of template the story template. You would say that it's of type my button component. So you would have my bottom component in the story and then you would pass the arguments. The arguments are essentially the inputs that the bottom takes, right? So the variable there that says primary is the first story and the first story in the first story we pass in the arguments that we want to show when we share that story. Then you can add a secondary and add different values in labels, label, background color and et cetera. But in the primary you just add some values there and let's see what it would look like with the values click mid, table salt and background color magenta. It would look like this. So when we serve it, our storybook would look like this. It would have the bottom as we said that it's a background color magenta. It is enabled and it says click me. Now you see down there that it has controls and it has some fields that you can edit. The controls are these arguments that we see here which are editable on the fly and we'll see now in a very short demo. So I can actually go there and in the label change the text that it says switch the toggle and also change the background color. And it would look like that I changed the label to hello there, I changed the disabled to true. So now it's disabled. The background color now is yellow. And if you look at the URL, maybe it's very small. If you look at the URL, all these different values that we added in the arguments are recorded in the URL. In the URL if you cannot see it says disable equals two, background color equals yellow and it should also save the text. So what does this help us in? It helps us of course, any three tests, right? Because in our E, three tests in our Cypress we say that go to this URL with these arguments, create this new component and then the item extract the content from here which is just a different iframe and it goes and checks inside the new iframe it's whatever we have matches what we expect to do. So this is the way the ETF work and Cypress works. On top of storybook. Finally, you can build and publish your storybook. Finally, you can build and publish your storybook. As we saw. What is the next? Nx is a suite of powerful, accessible Dev tools to help you architect and build at any scale, integrating seamlessly with modern technologies and libraries while providing robust CLI, caching, dependency management and more. Thank you Katrina. We did not understand anything, so let me explain. Nx provides generators, I'm sure. I hope all of you, since you're at an Angular conference have worked with the Angular CLI and you're familiar with Schematics and code generation. Mx provides code generation which helps you architect your workspace and generate code. It also provides executors. Again, if you're familiar with Andrew CLI, you have some executives to build tests, lead and in general automate tasks. You also have Migrators which help you upgrade easily using generators and executors. So if you do NX migrate from one version to the other, NX will go and change your code and adjust your workspace to match the latest version. So it's essentially painlessly upgrading to your versions and always making sure you're up to date with what latest versions of the technology to use. Also, Next gives you a big number of plugins. It integrates with modern tools like Slim Sidepress, Prettier, and of course we see today. So it gives you seamless integration with all these tools or another thing that it does, which is something that you can imagine. For Next, it does computation, caching and code base analysis. So you end up never building or testing the same code twice. What does that mean? It means that first it caches your code and then whenever you run the same task again, it fetches the results from the cache. But how does it do that? It makes sure with code base analysis to analyze your code base and understand which parts of your code base has changed. So if nothing has changed, it will fetch results from the cache. If some things only have changed, it will fetch things from the cast, from the things that have not changed and always rebuild or retest the change parts of the code. So essentially never do the same task on the same code trucks. Also, it provides distributed Pi Incremental, build Ti integration and Excel out and much more. I won't go deep into this because you can find these on our website and you can also find it on dedicated talks about this because if I started talking about each one of them, it would take the whole talk. So why one would use an ad from Storybook for design systems. So the amazing thing about the next is it will create storage for you. What does that mean? It means that when we saw the My button components, for example Per Angular, it has some inputs, so MX will go it will analyze your annual code component, extract the input and add them in the storage. It will create Stories for you, which means that and it will also generate the default storebook configuration for you. Which means that even if you don't know anything about Storybook, you can just run a command and generate Storybook configuration and it will take care of everything it will set up for you. It will create storage for you and then all you have to do is do NX Storybook and your project name to run it. So you don't need to write any code at all initially. If you want to go deeper, of course, and not do custom things, you will need to write codes, but it will set up everything for you. Even if you don't know how to use product, I believe. Also it will let you manage Storybook through the NX ecosystem, which means that whatever you do in storebook and whatever things you change will be added through the distributed cost and the code analysis. As I said, Cash results use Cash to touch them and it will also generate each pre test for your stories. Remember what I said about Cyprus? Well, when you run the generator or the Schematic for server configuration, it will generate a new E three application inside which it will import your stories with the URLs that we send for the argument. And then you can just run the tree test initially and so out of the box you have server configuration, created storage and a three test without writing one line of code. What's more, NX provides integrated environment for all your commands, so sort of has a CLI as well. But if you're using an X, you don't have to go into the trouble of learning how to use the storebook CLI from scratch. You can just use the MX CLI because it's an integrated environment and you don't have to remember many commands. Also we have the NX console which is a graphical user interface for the Nxlr which makes things just clicking buttons. Also it provides seamlessness and integration with your CI. It provides you the power of computation, path and code based analysis for your built and tests. And we also provide active maintenance and support. We're working very closely with the Storybook core team. Each new feature they have, they Ping us and each thing we want to fix or change within them. So it's a continuous back and forth. And old Storybook also uses NX for their codebase. So you can see how this relationship really brings things together. So how does one use it? If you have an MX workspace, you can do yarn ads in the Dev dependencies normal storybook. And if you have an angular application you can just do NXG normal angular storybook configuration and your app name and it will create the storebought configuration for you. Just what I said there. So what this will do is actually install the require dependencies all the storebook packages. It will set up the necessary scripts to run and build storebook in your angular JSON in your application file in your project Jason. Also it will add the default storage configuration and it will generate stories for your components. So let's see some demos. Now let me put this here. Now I'll show you the annex workspace I've been talking about for so much time. So here is our NX workspace, right? We have applications libraries and I have one library, my UI library. And in my library I have one custom button that we showed which is this one here which is exactly what we saw and the bottom stories. And I also have a link which has some different in place. It also has a number. So my stories. As you can see again I passed some things like this and in my package Jason while I was running all these install scripts it also added the storybook administratuals and the web pack five configuration. So now if I go to my annex console which is a plugin for vs code which you should add if you're developing with an X, you can see here that I have my projects and if I go in my UI project and run the storybook task and I click click what it will do is it will do ng run UI storybook or this can be written NX storybook UI it's the same thing. So business will go and run storebook for us and let's see how it will look. So now Storebook 6.3 started in our localhost 440 zero. So if I click here you can see what we saw before. Let's make this bigger. I have this button and I have these changes here. So if I go here and change this and change this and change my color like this, you see the button changing colors. Now if I go to my other components. The link components. You can see that storybook automatically analyzes the type of input that we have. So here it knew that true false was a boolean of course. So it added a total this is a text. It adds a text but here the text size. It knows it's a number so we can change it from this and this you can see in here that we can actually change the values of the component without needing to rewrite any code or without needing to restart anything. We can just use it and we can see that this UI library that we created only has two components so we can easily browse the catalog of components in that library. Right. So since I don't have much more time but I have shown you almost everything I wanted to show you. So we saw the generators and the migrators and we also saw the console. So let's wrap up so first one store to help you publish your design system, right. As you saw before, we have a couple of components, we can publish this at a live URL building and publish a live URL and share it with our team or whoever else you want. Also storybook helps us quickly test out various facing scenarios in isolation. Mx helps you use storybook by generating stories for you migrating your code and much more. We didn't talk about migrators but I briefly talked about the annex migrate command but in the Facebook package of annex you can see or I can also post a link where you can find everything you need. Also ANX helps you scale up with executors and generators, Alex helps you integrate storebook into your pipelines and the other thing is in sync with Starbucks team to address issues in time and fast forward for new features. This list of links you may need you can take a picture now or I can post it later on my Twitter and yes, that's it. Thank you very much. Let me see this.