Rapid UI Development in React: Harnessing Custom Component Libraries & Design Systems

This is the talk we've prepared for you today. So, yeah, welcome, everyone. Thanks for joining. You are in the RapidUI development in React, harnessing custom component libraries and design systems. So, yeah, thanks for joining. I think I just mentioned this for those that are experienced, that like the little thing, and that is GitHub repository. It will go in a browser or feel free to clone and install there in the background. We will have time for that also.

So, yeah, I guess we'll start from the top. Who am I? You are wondering. Yeah, I'm Richard. Curious engineer, most might look at the title, but I am a free agent, as of a couple weeks ago. I have been lead developer on projects for organisations like agni magazine, which is the Boston University, when I was a partner at Lyngess, the JavaScript start-up. Co-organiser of JavaScript London meetups since 2016. Like doing community things, hence why I'm here, you know, and also train developers from a variety of companies. I used to run React JS academy with Alex who some of you may have seen speak about micro front-ends at the conference. And, yeah, also, I'm a person learning to fly an aeroplane. That's one new challenge that I can answer! That's me in a nutshell.

Let's talk about what we're going to cover in today's workshop. So essentially, we will go through an overview of design systems, then will start to talk about the component library consideration, a bit about CSS and JS, then we will look at themeing, particularly in the style components library. This concept of atomic design will then have a look into style system, how that sort of works and various aspects that we can harness for our component libraries, then, in particular various theme components to give you a nice idea for how to do that as well or that you might consider publishing in the component library and see how you might do that in a company or outside of one. Finally, we'll take a look at Shaq4UI and see Shaq4 all the way through because I did exercises on that as well. As in the repository itself uses the component library, and we will see towards the end. With that said, let's stop and rewind, to briefly talk about the little bits about the component libraries and theming to get started.

So what is a design system? And why are they useful? There's a kind of I think it's useful to start with definitions that other people have given of what a design system is, because there's a few. And then I will give you mine. Here's a couple that I like. There's a lot of different libraries. There's there's a lot of different libraries. Everything that makes up your product, colours, icons, components, conventions, a design system brings together all of these in a way that allows your entire team to learn, build, and grow. And then we also have some examples of some design systems. I often find it's easiest just to see an example. I will show you, if you work at a big company, this is like, you know, Sainsbury's, it's a big company, it has several brands, it has like Argos and habitat and stuff, and they have a design system. I will show you. It's over here, it's documented, so their design system is called Luna. And you can come in here and find things like, I don't know, you can find all of these nice colours. That's great. So you can sort of see everything that's documented regarding these brands, right, so you can see that the logo is laid out. You can see that the home sign's layout, the logo's layout, this is all of the stuff that goes into the design system. There's this interesting thing which we're going to sort of talk a little bit about in a second as well, which is the design tokens. It's kind of an interesting concept, but fundamentally, they're just a store of value for design fundamentals such as colours, or spacing and typography, and so that you can get this cross-platform compatibility. You can actually go into the design system and check out pioneer, like, what does a design token really mean? The token itself is called brand-one, for example, what does it actually mean, you can actually have a look at the code base. I already had it open here. The answer to that is, as you can see, in the case of Sainsbury's, this is true for a lot, it's in SaaS variables. It's not just an image, it's a component library, and I didn't know that until really recently, so probably this is the case. So, yes, just a quick aside on that. I think it's really interesting, this concept where when we're talking about component libraries and design systems, we often think about the green-filled case, where it's like, how do I build that from the ground up. We are going to talk about this during the presentation as well, so I'm going to talk about what I think we need to do, and I will talk about the legacy things, because most often when we're working on the job, that's the situation that we face. Certainly, in my experience, several times, both at startups, scale-ups, and big corporations, there's something there, you need to work with what's there as well, so something to consider. But hopefully, that makes sense, regarding the definition. So here's mine, I guess. And the legacy parts are really important to this in terms of how we build the design to what we need, and UX, and design stuff. The design system sits in the middle of that. So it's this intersection between Dev and design, and it's bringing together the design and technical assets in a way that allows your entire team to learn, build and grow. So I got some of one of those inspiration from one of the others for that, but that's the sort of way I like to think about it. It's like, I'm going to use any of the d management language to build this. It's that idea of moving from a LIVNK, and getting stuff to render, to making it develop and redevelopable, but I also think that there are lots of components and dings here. I'm going to move into the power limits thing, so we're focused on the Dev side which the component library goes into that circle over there. That should be a reflection, essentially, of the design aspect, where you are able to show to the designers their code and saying this is the right thing to do, but it won't necessarily be dependent on the level of collaboration. I really think that is very, very difficult to do, unless you're a person, if you're a developer who already has a design background as well, so you're a designer who learned to code, maybe in that case you can do it on your own but otherwise I think it's super-super important. It is like a key thing in any organisation that's trying to ship quality products. Again, if you want to be able to size up your product in a interesting scale, a design system and implement that in a theme, then that should be respected in all the designs, right, this question of who has ownership? Ultimately both, but it is good to have that discussion with the design team, who owns this, and how do we have accountability about when it changes, and who is driving those changes and things. And, so, it is a really good thing to consider with design systems, I think, when to create one, right, because you could also use a pre-existing one. So this is kind of like a tech leadership question, I suppose, but in my opinion, it is kind of always best to try to avoid a premature abstraction that goes for both technical things and also the design things, and it can be a bit of a premature abstraction to already create a whole design system. And I'm not sure if this is going to help you, I don't know if you need to professionalise this, but a key okay after me would be if you have this need for sort of something that is used across multiple teams, working on multiple projects, and there needs to be a unified look and feel to all of that, that's where for sure it will really help you. Before that, there is probably other ways to do it, you could extend the existing design system that you're already familiar with, and you can do that later in the presentation. And you could also, the same goes for the component libraries. So, yes we can do everything like from the ground up, should we? It depends, right? Not a super satisfying answer but it really depends on the situation, and I think we have to like make this balance between convention versus configuration, and you get more speed when you're not doing 100 per cent custom, but of course you lose a slight amount of configurability, that's what I've made that side point.

So I guess that brings us to the component libraries. We are developers so we're going to talk about the components library side of this in the design system. So what is a component library when it's at home? Does anyone want to answer this question? I guess I'll throw this one out of the group, if anyone wants to go for a definition. Here is the slide. It's a package that I don't know if you can see this, something that can be shared like it's a group of components, some styles, like style system that's best used in different breaking and crumbling and shifting and saving as well as other parts. How do we get all of that information in one place so we don't have to share the same design so it shouldn't be implemented from scratch each time. — Yes, good answer. — So, we use a component-based library. So, these component-based architectures, all of this work with library is based on component-based architectures, like React, Vue, all of these are component-based architectures because it's really good for reusability and extensibility. And yes, that's our default approach. This is where a component library comes in. It's useful to have one because you can build multiple packages within the same, like, our developer-centric platform or bringing uniformity, like speed up the development of user interfaces. Cool. So, you probably have heard of some of these already. So, some popular component library, shakrui, we will see this one later on, favourite for developers, definitely, it's really good and I like it for lots of different reasons. And then we have React Components, which is a library based on material design, which was Google's, it is Google's design system. And, and design is kind of a popular enterprise component library, some of you may have heard of, and I thought I would put the classic Bootstrap on here as well. Some people went through and rewrote all of the sort of Bootstrap things as React Components. I don't know if anybody had the privilege of working in web, which I'm sure a lot of you have worked on in the past. So, this probably took 2013 through to 2016, 2015, 2016 before React and sort of component libraries in general were popular, like Bootstrap was everywhere. That was the thing. Anyway, bit of history.

So, yeah, let's talk a little bit quickly about CSS in JSC. So, we are doing a lot of work from the author to make it usable by the updates to the JavaScript library that came with ES6, essentially. So, hopefully, you're all aware of these kind of libraries, the CSS and JS libraries such as style components and emotion. You probably already know the benefits, but we'll just talk about it, very, very briefly, to recap.

So, essentially, it gives us full hand-held access to all of these libraries, which is amazing. And it gives us a feature of ES6. That's how it works. I've linked in the documentation, if you go to the GitHub repository, at the bottom, you have links. I've linked the blog post about how this works. There's another thing about how to use template literals in there. There's a lot of content there. I can't quite remember what template literals we had, but it was super new then and I still like it. But, yes, it's this idea that essentially you kind of can do style.button, it's like calling a function with those back ticks. We will see it in the code in a second.

Yes, I guess one small note about all of this, you can also, you know, if you really love CSS in general, partly because of all the updates going on in CSS as well, that is something I've missed is that both Python and CSS are quite strict on style. But if you're really passionate about going back to using CSS, it's always an option. There are no definitive answers to what's better, we can always assess, but for the purposes of this presentation, we are going to use style components as a library, so therefore, we are writing JavaScript, essentially. We are writing CSS, but ultimately what's happening every time is you're still there, anything you're calling style, you can always tell them, you're calling it. You can create a style component, which is your product.

So, then we're going to talk a little bit about what happens when you have a legacy codebase with a bunch of styling. You may have worked in places with things such as this, you may have some non-React components, so what I mean by that is just standard JSX components, and you have a bunch of different styles you might want to keep in that. So, what you can do like this is pretty straightforward. Hopefully, everybody on the course is familiar with this. You see the chapter wrapper component, you would just be like, okay, that's now style.div, use the backticks and the tag template literal is going to do the styling in there. You can do that, that's pretty straightforward. You might be thinking, what if I want to keep some legacy styles? You can declare my style components, like the attributes, and you can just use that. It's the first and only argument of an object merged into the rest of the components prompt. It does quite a bit more than this. I do recommend having a look at the documentation, which is linked here, but one thing I would say with this as well if you're going to do this, it's a little bit messy. You need to bear the specificity in mind. So, anything that's going on, and I'll show you in a second in the code as well, but anything that's going on in your legacy styles, it's going to be overwritten by the style components, like the specificity goes component first, so everything written here, for example, if I've got that border-bottom here, anything that's in that class name, it's going to be overwritten by that. So, just bear that in mind. Normally, you want to try to avoid as much as possible competing styles, because that's where we get into this mess where everyone starts to put the important explanation, and we want to try to avoid that, so avoid as much as possible, but, you know, you can face in to circumstances where you just need to do that, and you want to have some flexibility, so, yes, you can do things like this.

Cool. Just before I show you the code, I just wanted to give a quick aside as well about abstract components. And just making a small abstraction upfront. So, I would highly recommend this. It is just something from my experience and I've done this a few times now in a few different places. Companies of different sizes. It is often overlooked, but it can cause you issues down the line. If you're using a pre-existing component library, I would highly recommend that in your projects, in order to plan for change, you just make a small abstraction which can be as simple as make a new file, import the button as like whatever the component library button is from the MIUI button and simply export it again. Why would you do this? If you need to make changes, which you probably will down the line, you do it all in one place. Quite quickly code bases, if you start importing things directly from the component library, that can be fine to start with, but then you will find over time often it is like people make slight adjustments to these things in a ton of different places. Or you can make multiple different files, and that can be really hard to unpick later. It is just planning for change. In some ways, you might be thinking, it is a premature abstraction, but it is costing you making a file, to be honest, at the start and it will just help you and give you flexibility down the line. So, yeah, and also the thing is if you later want to switch or swap out the component library, you would just come here. And now, if you are using, I don't know, the chakra button, I mean, it is half a minute, and that is fine. You can use more than one, I wouldn't recommend that later, but use the one and it will take affect across your entire application, because it would be broadcast. It is something to consider. I would note here, if you are starting from scratch, this is the same thing you would do anyway in terms of your code structure. You would have components, you would define your own button. Components, you can say, for example, typos, and so on, but it is a good example of how these things in style components get extended, so you can parse a component and it gets past as a function. Then, you can over-write styles on top of that in a normal way. Cool. Hopefully, that will make sense. And, yes, another really good trick that you don't have to worry about is SangPress. You can use the SangPress as Sass variables, JavaScript variables, and you can use them directly. This is overlooked. Often people run into this situation where they're like, well, I want to use style components in the legacy code base that I want, but I need to use the Sass variables, that is needed. I've got an example in the code which I will show in a second of this, I just don't think that you have to go on a little bit of a hunt, but ultimately, as we saw in design system, there's going to be in a big company some Sass variables which are used for styling, and that's going to be stuff like the brand colours, and you can probably find those, and that's really, really good, because then you're always pointing at the original source of truth. So you don't want to just, it's easy to find out what, like, the hex codes are, whatever, but you want to keep pointing at the same place in case somebody comes along at a high level tomorrow different, and then, like, taking the randomness, you know, it clashes with another colour, or perhaps an accessibility consideration, for example. Any of those reasons. And then, suddenly, you know, your project is, like, off, and you might not realise for quite a while, and the whole point of these design systems is like bringing, sort of uniformity across all of the different products, so, yes. Also, yes, you can fully adopt CSS and JS in a new project, so yes, these are all good. So, I don't think we have any questions about anything I just said before we have a quick look at this coding stuff. I'm going to do a quick demo for this one, and then I'm going to stop talking, and we're going to do an exercise! So I was aiming to show you this code in less than30, 40 minutes before letting you do decoding. So, I just wanted to show you this. Cool. Let me just share, I need to share my whole screen.

One second. Okay. Okay. Can you see the code, as well, now? Yep. Okay. Thank you. That's really helpful, actually, having the thumbs up. Good. Okay. Great. So, we can see these two things side-by-side.

Let's have a quick look at the application and, actually, one thing I'm going to do as well is open the repository in a new tab. Since we're looking at it for the first time, so just quickly, yeah, this is the repo. So, hopefully, many of you have already done this. But if not, please feel free to do that in the background. You should be able to get it running. You can follow along with this part, but your exercise is coming up in a second. What I would say is the instructions in the readme are quite concise. So, if anything, just reference there. But feel free to ask me or send me a message, as well. And I can explain a little bit here about the folder structure, et cetera, that we're going to look at. So, I won't repeat that now. But, essentially, it looks like this. It's very simple. Each exercise has a heading. Everything is separated into example and exercise. So, I'll be showing the example stuff, and then you'll be doing exercise stuff, basically. And then we will do some wrap-ups after each one.

Cool. So, let me show you what I wanted to show you quickly on this one. So, you see here, what we essentially did is we had this situation where we want to use our legacy styles. What do I mean by that? So, we have some legacy styles. We imported them over here in the index, right? It's got this legacy... it probably won't be called legacy styles. It's probably whatever the base foundation is. But anyway, we have some SAS that's been imported, right? It's in the project. And I can show it to you over here. So, what does that look like? It's a very basic SSS, but this is operating. So it's all there. And you can see we have some classes and things. So, and you can see that we have some SAS variables. Now, these ones are brand colors. That's why they have fun names. And oftentimes, you will see exactly that, like it has sort of a fun name, right? What do those variables look like? Like this, it will probably be a little bit more convoluted, right, on a big scale, but obviously, I've simplified it down. Like I said before, you probably have to go on a bit of a hunt for this. I've certainly had that experience, but you can find them, they'll be around somewhere. And once you find them, you can, you can do what I'm about to show you and export them. So anyway, these are our brand colors. If you're curious about where I got them, I got them from this Flat UI colors. You can go and have a look over there. It's this US palette, but so what did I do with these? Having found them, so we found them, I created this export folder, where simply you just import, all of them import the existing Sass variables. And then you can export those as JavaScript variables. What does that mean? It means that over here in the style components, I now have these brand colors, and then they are like you can see them all. And we can actually go ahead and use them. You might be wondering about the type scripts, that's something I wanted to show you just quickly as well. Over here, what I did is just simply type them. What I would say is if you have a lot to do, you can actually auto generate them. There's a package called type CSS modules, which will help you do that. But to be honest with you, you can actually do it as you go through. If they don't have types already, it might be useful to do it, like intuitively and sort of do it yourself. But yeah, if not, you can also auto gen them or if they're liable to change might be a good idea to also generally as well as things to consider. Okay, so let's go back here. So let's also have a look at this attr thing that we saw. So yeah, we can essentially do this object. And now in here, I'm going to pass it this class name. And I'm going to give it that box. There we go. And now over here on the left in this little Hello, we should see the result of that in a second, once it decides to load itself up. You might be wondering, yeah, there you go. So I don't know if you can see but essentially, it's just giving it like a border.

That's the difference. So what happened there. It's just the stuff that was applied in here, right? Here's the box class. Here's the border. And now it's got that border with this American River SAS variable, which points to the color that we just saw. Yeah, and like I said, just out in the presentation, just bear in mind the specificity, right? So like anything, all of this would be overwritten by what I'm doing in the style component. So it's also just kind of something to bear in mind. So any buttons would have these defaults, but they would be overwritten. So, yeah, that's that. And then yeah, we can have a look at changing the color. So let's say I want to change the color because we've got all the typing it will like suggest us all of the different colors. Let's do this mint leaf but it's pretty cool. This is the good thing about this entire script to suggest you all the stuff you've got. But yeah, we can just use the brand color. They go is changed in new leaf now as you can see over there on the left, hopefully. Cool. any questions about this part? If that all make sense? I'll take it as a yes. All right. Nice. Sorry. Richard, I have one question. What is the best strategy? The best approach in naming this like CSS starting very variables. For example, for colors, for like some borders, I don't know, do they need to be like related related to some part of the app, some components where you use it? Yeah, I would say, in this example is where the SAS variables already exists. So probably somebody else named them. So you don't have a choice. So the example we're talking about is where you don't have the choice. But it's a great question. I think if we're creating our own theme, that's our decision along with our design team, right. So I think, generally speaking, it's quite a good idea to have semantically named things. But what I in my experience, what I've seen a bunch is the brand colours tend to have a specific name. It's sort of what we saw over here with the lunar thing, right? Like these, these colours are shown like these colours have, you know, they might just be called like brand one highlight of something. They also can have, let's see if I go into the Sainsbury's colours. Yeah, like orange base, orange dark, plum base, they tend to be named semantically. Hopefully, that answers the question. But in as I said, in this example, it's we're assuming that they sort of already exists. So I wouldn't change the names of them necessarily. But when we're creating our own theme, which we'll see in a second later in the presentation, we're doing the exercise, then it's kind of up to you how you call them. So yeah, it's definitely worth thinking about that. And discussing with your colleagues the way that would go about doing this. We will go into a bit of detail on towards the end as well, is to write an RSC request for comments. So you sort of make a suggestion, right. And then you ask people to weigh in who do you ask to weigh in the design UX, like and design leads as well as the developers so that there's some consensus about naming because naming is hard. That would be my suggestion. Yeah, yeah. And there is one more question I guess I like forgot to answer when you've been like showing the first part of your the workshop is, what is the high time for like, usually, like we start when there is like some MVP or something we start using some component library existing and customizing it, what is the high time of like creating your own component library when when when we should start doing that? Yeah, great question. I mean, what I would absolutely start with is the thing that I was mentioning before. Abstract them like definitely. Where is it? Make sure that you have come past it, make sure that you make these small abstractions because then essentially, you can start in a really easy way. This this part, so you're bringing in like others make this abstraction is going to be the thing that's going to really help you like make the jump to doing your own. I would say the moment you want to start doing your own. It's a tricky one. It depends. It all depends on like if you can. If you can see that the way that it's going is there's going to be multiple teams working on multiple different products that you 100% like want to do that. You might want to do it sooner as well to bring some design consistency with your designer. Like that's a good idea. But what I'd recommend at that stage rather than building out your whole own component library, it's like modifying somebody with these abstractions. So you make an abstraction, you make some modifications on top of someone else's, especially one like Chakra, which is easy to compose. It's really extensible, it's super flexible. If you use something like that, and you extend from their theme, that will get you quite far. And then you can sort of take this decision to get full flexibility and build your own. Another reason you might want to is when you have sort of some legacy stuff around. This is often what happens. It gets like a bit messy and then some legacy things around and then you see that it's just getting bigger and bigger. In terms of the need for consistency across different code bases. That's where it's good to start pushing for it essentially. But there needs to be a consensus and that's the thing that's can be tricky. It's kind of like a tech leadership thing. And that's why I always, again, I would start with that RFC, you know, pitch it essentially and be like why? Why now? What's the pain point in particular that we're facing now? And what will this unlock and get buying from people to do it because there is going to be a bit of upfront work right with building a component library that there always is any change there's a bit about from work. So yeah, hopefully that answers the question.

It's tricky. There's no definitive answer, but some of my sort of like, OK, ours is that. Yeah. So anyway, like we should start like having, to start our project, having some shared library where we like, put all our like shared, like, common components with these like styles, even if they whether they like customising some library or not like so like putting it in one place. Exactly. Yeah, making those small abstractions. So you have like some folder which is like your button you should have some button, for example, or like accordion or whatever it is, even though you're using them for another one, I would highly recommend making that abstraction even if you just import it there and export it back out because then it's going to make it really easy then to change in the future either to change library or to build your own on top of that.

Thank you. Awesome. Cool. All right. So onwards, we'll do an exercise in a second. But um, let me just put this back. While so I'm just going to close some of these things down so it's not to see styled components over here. Yeah, alright. I'll leave it on that one. So let me know if the code isn't big enough by the way, or if you can't see the slides, I think what I'll do is just leave these side by side so that I can go back to the screen in a second. But question for all of you, I suppose, why do you think we need a theme? We're going to talk about themes now, but what do you think? What's the point of having a theme? Is it so we can kind of change it as well, if we, we program to have a theme, we've got all the variables in one place, and then we can change them if we have to make like a dark theme or something? Yeah, yeah, good answer. Pretty much. It's essentially this idea of having a single source of truth. I think that's the way that I think about it. For our brand colors, we can eliminate the repetition of frequently used styles as well. And as you just said, it's like if we have some variations, we can drive them from there. And the theme is a sort of document that you this sort of should be the code representation, I suppose, this is how I think about it, like the code representation of what's in your design system. The design systems often live in like Figma files, or they live on web pages, like the one I showed you. But yeah, there should be, to me, if you can get it close to that, then it's great. So, let's have a look at some on the screen. So yeah, theming. Let's have a look at how to do a theme with style components. It's pretty straightforward, to be honest with you to implement a basic theme. In essence, it's just a plain old JavaScript objects project. So, how do you do that with style components? Well, you bring in this theme provider from the library and then you just need to pass it like an object. So, we're literally passing an object with one key and value, key being color and the value being medium C green and then yeah, if you have this box, you will get it will appear on the props of all of your style components. Like, literally anywhere in the application. If you do this, like props of theme color, it's going to pick up this medium C green for example. And you can see that in the documentation over there. And I will show you in a second as well. Also, themes are super easy to extend. So, touching on what was said a second ago here, right, you can do stuff to like create some base styles and then you might also create like an object that has all of these things like a light theme or a dark theme. So you might have more than one. That's pretty common as well. Regarding light mode and dark mode, I think most of the time that particular feature has normally is already been implemented, to be honest. And some good component libraries will have that and you can do tricks like just sort of inviting the color. I will show you how to do it in a moment. But you do sometimes have these cases where you want to do that. And one of the very powerful things that we have, one of the other ways is by using variance. That's the thing that happens much more commonly. You have a variation on the same thing. You have one theme, but you need, you know, you have a primary type button and secondary type button. That's very, very common. But anyway, that's it. Ultimately it's just an object. That's what I want you to take away from this slide. And that makes it easy to extend just using normal JavaScript features, because you can just spread some values into another object, and you know, then it's going to be, you just pass the result of that to the theme, and you're going to get the same result. What would the theme file look like? I'll show you one over here in the code, as well, in the theming. So kind of like this, yeah, this one actually is the one on the left. So it's super simple. It can be as simple as this. So colors, and then you can name this whatever you want. And bear in mind that it's JavaScript, right. So one thing about this is, and this is where the CSS and JS thing comes back again, as well, is that, in JavaScript, obviously, we need to camel-case everything. So, when it comes to any keys that happen to be, like, referencing CSS values, then it's going to be camel-cased, like if you have some sort of justify-content center or something like that, it's not going to be a dash, it's going to be camel-cased. Here, very simple, we have colors, we have blue, green, and background, but in the more complex example, this on the right-hand side, this is what I was showing just now on the slide before, you might have some base, light, dark, and then you can switch those out between each other. We will build up from the simple one, because, generally speaking, you tend to only have one. Anyway, we will talk about it now. Yeah, I also want to talk about this, you can quite easily allow theme switching. It is just an object. You need to switch which object you're passing to that theme provider. One of the solutions you will see is very common if you look into such things is using context for this. Context is very good for, as a sort of global state solution for any sort of ephemeral value in the application.

You need to broadcast all of the components anywhere down the tree. Obviously, you might have another global state management solution going on so you can also store it there. Often, this is one of the examples you will see quite widely along these lines where you use context and then in the app, in your context, you have some state and then you just decide, based on that, you have a sort of map between this light and dark and then it just decides at run time which one to use. That is kind of how you do it.

The reason I'm not dwelling on this is because it's not really the main point of the presentation and there's a little bit to dig into about it but yeah, another reason is as well that good component libraries will already have this. This is kind of like a solved thing. It's funny back in, when was it, like in 2018, building these was like super-super fun but now I feel like everybody already has lights and dark mode so the likelihood of you actually having this enough is not that high. It's more likely that you'll see that there will be a product where, for example, this is a use case I can see, where different users see entirely different themes. That happens sometimes, especially with software as a service product where, I don't know, one set of users, I don't know, has a premium account or something and now it's like the entire thing looks different? Okay, there are two different themes there for sure. But also you can imagine totally different brands, right? Sainsbury's, as well, they have the brand's coloring for something like Nectar is totally different from the brand's coloring for Sainsbury's, which is all the orange and then Nectar is all this purple stuff. But, yeah, the most common thing, and that's what we'll see, is variations within a single product. That's the thing that's really key. And this is the thing you'll probably face into, where it's like, well, I have some sort of two different types of buttons, right? I have a CTA button. I have a primary one and I have a secondary one. And this is something that we really almost for sure will face into. And that's where the theme file can also help us.

Yeah, I think there's a question. Yeah. So, Richard, do we need to add premature theming, or we shouldn't create theming unless we have a case for that? I think it's good to have some. I think that the theme, and as long as you can get everybody to agree on this, and again, this is the really key part, it's a really good thing to create because it creates like a single source of truth, right? So as soon as you're using style components and you've got some colours in the application, instead of having that sort of spread all around, and you've got these sort of different hex codes in different places, you have that in one place. That's the real, I think, power of having the theme, so everything should just reference that. And as we saw before, that's really easy to reference in the style components, so if nothing else, I would do it from that for sure. And if, like, if we can use CSS, can we, like, for the first version, use CSS variables just to store a needed theme in CSS variables, and when there is a need for, like, different themes, then we can use some other tool for that. So, you can actually, the thing that you can do is you can, if you have those SASS variables hanging around, you can bring those into the theme, and then everything is driven from a theme, everything in the application, because bear in mind that if you're using style components, every single style component has access to that theme object. It's like something global, so it's very powerful for, you know, your source of truth through the colors, and then if you need to add a new color, just add it there, because then it's available everywhere, and everyone's going to love it, and if that changes, because your designer tomorrow says, oh, I need to change the shade of the orange color for whatever reason, you change it in one place. I think this is like for me, a really, really key reason that you would want to implement a theme, it's that single source of truth piece, and like bringing that consistency of where everyone looks. But we'll see it now. You'll see the power of this I think now. Hopefully it will be in the exercise there. So let's do the theming. Let me show you the example quickly, and then I'll get to do some coding, because I've been talking about the look of it for about 40 minutes, so let's have a look at the example. I like to, it's really good I think always to just keep stuff simple, and then we're just trying to build up, right? Maybe for some of you, this is super simple, it's too simple, that's true, but we will be building on top of it, because the kind of key aim here is to get the basic concepts 100%, and then we'll build on it. So let's have a look at this example.

Here's the basic theme example. This is my styled theme button here. When I hover on it, it goes green, it's like blue, and then it's green. Wonderful, so here's the button component, which has been written as a style component, which we saw before, and as I was saying, all of them have access to the theme via the props, so I can say here, props.theme.colors.blue, you can also do stuff by the way, like, I mean this is not really related, it's just JavaScript stuff, but you can do your destructuring and the parameters and stuff as well, that would work fine as well. Things like that, just to tidy it up a little bit. But yeah, that said, you can see that it's getting the stuff on the theme. So this props.theme.colors.blue is pointing at the blue in our theme over here. So it's this blue, this green, and of course now you also have the opportunity to name it whatever you want, so that's also cool. It's coming back to the idea we said before, like, how do we name these things? You need to get some kind of agreement on the naming, which is tough, but yeah, it's cool because now you can name things semantically. So there's also that as well, which is nice because I think when somebody reads it, it sort of lowers the cognitive load, right, because I don't know what blue means exactly. It could be any type of color blue. Yeah, hopefully that makes sense.

So you can see there's also like a wrap-up component here. I'm also using the, I'm just using the background color, which is that light color there. You can also have a play with this. And then, yeah, here I'm just passing the theme object, as we talked about. There's something here, too, that I was going to mention, which is that you can make use of TypeScript's type interface for the theme object. The way that you do that, generally speaking, is like you just declare Star Components as a whole module, and then you just extend it from the base thing. The thing is that because of the way this project is structured, it's going to complain probably about the other files because there's more than one theme here. There's sort of a theme in every folder. But essentially, as you can imagine, that's now giving you the type safety. So when you're typing this, now I can see right here like, what are they? So that's also something that I would definitely there you go, it's complaining, of course. Which is kind of to be expected, but if you're doing it for real, I would absolutely be using TypeScript. Absolutely have a think about these things. It's a little bit of work up front to like make sure it all works. TypeScript often is, but it speeds us up later, and it's really helpful for other developers, so I would recommend that. Cool, so that's kind of the example. Does that make sense to everyone? I'll just show you like if I change this one, just proved it. But it should change, so now I'd expect this to change colour. There you go. The colour changed to green. Cool. All right, let's have a look at the exercise. Is there any questions before we have a quick look OK, let's do it. So if you open up theming and the exercise folder, and the other thing I would do is open up to read me. And this is the first one. So yeah, it's not seeming open up exercise.

So your task here is kind of to implement the themes. Yes, so I've put some comments for you for guidance. So the first thing you need to do to get this going is wrap the whole component with the theme provider for our components, then create a simple theme, like whatever you want. I would recommend adding some colours maybe. So I've given you over here, maybe add some colours. You can have whatever you want. And then implement the colours that you've created and just try to get that working here so that it makes sense.

So what we're trying to do is essentially style this card, which looks a bit sad at the moment. Let's try to get some colours and things going. There's a couple of bonus things here that you can do as well. Remember what we saw about the legacy theme colours? We'll do this in the recap. I'll show you how to do it. But remember what I mentioned? You can actually input, if you think about it, in this file I could input those sass variables, which I created the JavaScript export for, like the JavaScript variables. So I could get those colours going here. Right. That's kind of cool. So, yeah, that's a little bit of a bonus task for those of you to get this going quickly. And then the other thing is, yeah, have a go with like playing with TypeScript. You have the example. It's commented, but see if you can get that to infer all of the types in your theme. And then, yeah, try extending it by adding some base styles in the presentation if you want to take it even further. But I think in the interest of time, I would say this one. Yeah, we'll just do some do it relatively fast, maybe like 15, 20 minutes. And then we'll do a recap of this because I'm quite keen to move on to how we use style systems to sort of give it a few more superpowers. So yeah.

Any questions about the exercise before we start? How or what I'll do, by the way, is I'll create breakout rooms, automatically assign all of you to these, probably like five or so people per breakout room. You can pay a program together and talk to each other. I recommend that. Or you can do it yourself. That's cool as well. And I'll kind of come around them. Is that I'm going to get to all of the rooms. And then what I'll do is bring you all back into the main room in sort of 15 or 20 minutes and do a recap. If that's cool. Any questions before we do that? Does it make sense, the exercise. I highly recommend having it have a look at the examples as well. That's the real key thing with these exercises. You have an example. So have a go. Cool. OK. Seems like there's not any questions, but if anything, just feel free to ping me in the Zoom chat or in the Discord if anything else I think that there's a few things in the chat as well. I'll respond to the things in the chat while the exercise is going on, too. I think that. Yeah, so I haven't responded to those yet. Cool. OK, let's do a quick recap. We're going to do something more complex in a second, though, so I hope you're feeling good and warmed up from that. Yeah, hopefully it was pretty straightforward. Let's give a quick. Can you see my screen? Yes, cool. It's worth checking. Yeah. So essentially, yeah, we could implement the theme. I implemented like the bonus I was telling you about. So put in the brand colors, spread them here. Right. And from that legacy export folder that we saw at the beginning. And, yeah, I could also use those ones. Right. So here I'm using this chime moment or whatever. I could also use that was it called? Mint. Mint leaf. Yes. And we should also see that pop up. So really the key takeaway here is yeah. This is how it's implemented feeling in style components. There's nothing much to it, to be honest with you. Snob Jaxx hopefully you got the chance to sort of play around and get used to how it sort of works. And hopefully something maybe even go to the TypeScript as well.

I've got the legacy stiles going too. So that's sort of basic theming and how you can start to use theme files. Any questions about any of this? Is it all making sense so far? Cool. OK, let's move on then. Because we've got some more stuff to talk about. So we're going to get it's going to get more complex in a second, although technically speaking, you know, the funny thing about theming is like if you look at the style components docs in the advanced section, so you've entered the advanced section, but I think it's pretty chill, hopefully, so.

All right. Let's build on top of what we have just seen. How can we extend this and what are some of the limitations? So I just wanted to talk a little bit about this concept of atomic design as well. This was introduced by a guy called Brad Frost. It's the concept that web elements should build upon each other like atoms, molecules, organisms, and so on. Another thing that we should have a chat with our lead design UX person about, as it's more on the design side. But it's quite a powerful concept. This can be a little bit hard to follow with star components, and we'll talk more about that in a moment. In terms of how we reason about what is an atom, molecule, organism, template, and page, for example, a button element would be an atom. If you have a star component button, then it's becoming a molecule. A component that ingests the button would be an organism. A collection of organisms that make up an experience would be considered the template. Templates make up a page. This is quite powerful, but it's easy to deviate from this.

But also an email input, etc. And then templates make up a page. So, yeah, pretty straightforward idea. But this is quite powerful. It's easy to deviate from this. Believe it or not. That's the funny thing. So, yeah, so this is where we're going to talk about star system.

So star system is a set of utilities that can help us overcome some of the limitations with star components. And essentially make it more flexible. And we'll talk about those limitations now. Sharp for you, I actually quite heavily on this. And so there's sort of several other component libraries. So just a way of making it super flexible, which you will see now, it's quite a powerful tool.

What are the limits of star components? What do I mean by that? Well, the thing is star components along with the theme can take us a long way, but they can kind of get quite large and chunky when we need to run a lot of different props based styling for different cases. It's just great. We can do like stars around time. That's what star components does and allows us to do based on props. That's wonderful. But it's so easy to get like into this kind of mess. Like we're seeing here, it doesn't look so bad, maybe. But imagine using more properties that need to be modified, like, you know, like I've seen in code bases. Oftentimes, like these things really can get super chunky and just becomes really hard to manage because what you're trying to do is you both want a default set of styles. But you also want to retain the flexibility to overwrite whatever those defaults are. So you've got a reasonable set of defaults for your styling. And then you also want to create a situation where the developer was kind of a dev experience thing, I guess, can also just be like, well, in this particular case, I want to adjust it. You want to be able to do both. So yeah. Let's go to the next one.

In a nutshell, what is StyledSystem? It's a set of utility functions that adds styled props. What are styled props? I mean, we've been adding styled props already. This theme is almost like a styled prop as well, right? But you can add them. You saw it on the last slide. You can add your own custom props. So, like in the case of this one, we're like adding this size prop. So it's essentially the same. It's doing the same thing under the hood. But it's doing it for us as a utility, which is really handy. And it's based on, like, a bunch of really well thought out patterns. So it allows you to control styles based on a global theme object with topographic scales, colors and layout properties. This is something that works in tandem with CSS and JS libraries, like style components and emotion. It's not a replacement for them. So, to be clear, it's like trying to work in tandem with them. You can't implement style system without – you can't implement the utilities, to be honest, not without style components unless you built your own version of that as well. So maybe you could find a way. But, yeah, that's the way to think about it. And, yeah, it's pretty – used pretty widely in terms of increasing flexibility in off-the-shelf component libraries that we see around. Yeah, it also comes with default theme, by the way. So that's another theme specification, both of which I highly recommend looking at. The other thing is it enables the use of variance, which we're going to talk about in a second as well. That's very powerful. So essentially, we can just do these variations which are all sort of driven from a theme. Yeah, and that will help us cut down on repetition in styling. Cool. So let's talk about style systems. So how does the style system look? So you import these utilities, and then you can see over here on the slide that, if you've got these base color and layer utilities used there, and then you can just go ahead and do all of your styling based on these props. So it just gives you a default set of utilities, which are, as I said, really well thought out. One thing I would highlight as well is that you can decide whether to use the long form or the sort of terse, or the short form as well. So this N, that's margin. You can also write margin. This BG is background. Like you can write background. In case you sometimes you see code bases, and it looks a bit like what are all these P's and M's and stuff? It's just that. Obviously the reference for this sort of the best reference for all of this stuff is documentation. We go over here, not the box, but we go to the API. You can see here the API for the space. So this is what I was talking about, right? These are the props it's giving us, like the margin, top, right, bottom, left, etc., etc. So you can sort of see all of that stuff. Cool. So yeah, essentially there's also, maybe I'll just show you in here as well about the style system.

I think it's, yeah, let's talk about variants first and then I'll show you the demo of the style system and the code. Let's just keep it in that order. Anyway, but there's the example over there. So let's quickly talk about variants first.

What are the variants? You can use – and by the way, you'll have an exercise to do both the style components, but also the style system, but also the variants. The variant API is essentially used to apply complex styles to a component based on a single prop. So this is a handy way to support slight stylistic variations in a button or typography components.

How does that work? It's pretty – it's relatively simple as well. You input the utility variant. Well, this is one way of doing it, by the way. You need to give it a key. You can also use the word scale there just to add confusion to it, but it makes sense that they change that because if you think about it, it's a JavaScript object, so key is not maybe the best name. And then you can apply button style there, and now what it will do is go looking in your theme. It will find the buttons scale and it will apply the variants from there. So you can apply that at the bottom of a normal style component, and here I'm giving it a default prop as well of primary, and then you can see over here on my button that I've got this variant secondary, and I'll show you what it looks like in the theme file. So over here it's coming in, it's saying like buttons, okay, cool, and then I've defined the variants as being primary and secondary, so if it's primary these are the things it's going to get. If it's secondary these are the things it's going to get. So the result of that is this. So you can see here in the variants example these two buttons. Cool. So let's have a look at the codes because I know that was quite rapid, but I think that explaining it in the code at this stage is kind of easier. So I'm just going to go back here. So let's have a look at the style system example. So here's a basic example. You can see this box here. But what I was talking about, the sort of superpowers that this gives you, is that if I'm saying if I think like padding four, I don't like that, I want it to be smaller, I can literally just change the number there and we'll see that that gets reflected. There you go. Now we've got like the padding of 3 all the way around. You might be wondering what are these numbers referencing, and I'm going to show you that in a second. But it's the same thing with the background as well. You know, you can actually put any colours here, but what it will do first is go look in your theme. If that colour is defined in your theme, it will take the theme colour. If the colour is not defined in your theme, it's going to like take the default. So you of course could pass like a hex code here or something as well. But essentially, it's giving us the power to just choose, right? So I've also got the Find in My Theme Colour as background. So if I wanted to, I could go over here, and give background as well as a colour, and it will just go find that in the theme, and it should update it to whatever I defined in my theme as the background colour. Cool. Hopefully that makes sense. I want to talk quickly about these numbers as well. So over here in the theme, you have essentially what it does is implements a decent space scale. Again, this is something that – and this is one of the first – the first things you'll probably do when you're doing component libraries is colours and spacing and layout stuff. That's, generally speaking, a good place to start anyway, especially the spacing. This is something that I highly recommend you talk to your designer about as well, like what is the spacing scale? And then make sure that you're always sticking to that spacing scale. So if you then receive later, any sort of Figma designs or whatever which don't stick to the spacing scale, that's something that you need to pick up and have a joint responsibility for. I think one of the things I like to do is actually try – well, if you happen to work with a designer who's interested in coding a little bit, is have them take ownership really of this stuff completely, like the file. If it needs changing, then that's cool. Have a discussion about it and change it. So it's an array, so from 0. So if I did the number, four, zero, one, two, three, four. So we're going to get like 32 pixels in this case. Yeah, pretty straightforward hopefully, but yeah, it just gives you this kind of flexibility to do this type of styling very rapidly. Other things to mention. Yeah, this is how you do the TypeScript. So the library actually exports those types. You need to create a type. You'll need to pass that to a style component. And then you can just add these utilities. Hopefully that all makes sense. Let me just, I'm actually on the wrong branch. So what I'm going to do is quickly switch back to everyone. Sorry, may I ask a question? Yeah, yeah, please. Could you show one more time the theme file please? Yes, absolutely. Very simple theme file again. How does Style System understand that amp-props are related to space theme prop? Yeah, great question. So Style System as is developed in the space ones in particular. It's essentially the default so if you have a look in the documentation with the theme specification… Style System is what suggests how you need to name them. Corelate margin, bottom with that theme. Exactly. This is something we'll talk about later. When you're thinking about building your own component library, and you're looking for a theme from a library, you might want to look for a theme from something like this.

And actually the Chakra UI Component Library, they use this theme specification like this is what theirs is based on as well, right? So in response to your question, definitively, yeah, it's expecting this stuff. So it knows the colors, it knows kind of how to go looking for it. And that's why when I go because backgrounds is coming from the color utility, it's going and it's going to the theme and it's expecting to see a key called colors. And look and be like, well, do I have blue? Yes or no? If yes, I apply the blue from the theme. If no, then I apply whatever the default blue is. Right. So it's flexible like that as well. And like I was saying before, you could also give it some sort of the code. It would work like it would be absolutely fine with that as well. But it's always good to just drive stuff from our theme. So that's kind of cool that you can do your background color set to find them up here outside as well. It's just a JavaScript object. So we have a lot of different options. That's also one of the things always worth discussing with the team, like how do you want to go about doing this? Do you want to put them in line? I would pull them out so that they're just there in one place and it's very easy to change. Anyway, that's something we'll talk about a bit more later because we're building up to it. But going back to the example. Yeah. So like here I can just go for backgrounds and I should not looking at it now. They just picked it up from the theme. So.

Cool. So that's a basic example of how to style system utilities. You can just pull them in and you can just start adding those to your start components. And then you just get all of this stuff like for free. Essentially here I've just used space color and layout. So I'm using layout because I wanted to do the width. Like I guess I can demo that one quickly as well. There were a bunch more. You could add more. You could add as little or as many as you need. Often a fully featured component library would just like add all of them. That's why in Chakra UI you tend to see when people are using Chakra they're just doing props based styling for everything because they added all of those in all of their default components. You just have access to this stuff. How can we use relative units for spacing for example? Oh, you can do that as well. Yeah, that's fine. You can just define in your theme, you can define all of those as like ends. And I think actually over here in the theme specification they talk about that. Yeah, there you go. So you can just use them, simple answer to that question. But later I'll show you, and Chakra have a good example of how they do it as well, like how's their default theme done. You can also see that there's a couple of nuances with this, but essentially just use ends or rems if you'd rather do that. So we just need to put in the theme in the space in our array of spacing using units. So not just numbers, but with units. Exactly. These numbers are just going to default to pixels, but you can do that. So it gives you full flexibility there. Cool. So that's that one. Let me show you quickly the variance as well. Well, let me show you the exercise while we're here talking about this. So yes, your task here with this exercise, I'll just put it on here as well, with the style system is import the space and color utils, apply them to the styled button component. Try sort of changing stuff, try out the padding, background color, don't forget to reference the API to see like which props you can pass, et cetera. You can play with that and also have a play with some of the custom styling. So, yeah, and have a look at styled component style systems specification, what we were just having a look at. So it's a pretty straightforward activity, I think, as well. Yeah. Just have a go. So I was adding those in the bottom here. And that would be that one. Should be quite quick. I'm going to give you two though this time. So you'll have another one to move on to. The other one I want to show you is the variance that we were talking about. So if we go back here, have a look at the variance example. So here I've got this. This is something that almost for sure will come up. What I was mentioning before is the most kind of common thing, that you have a variant, and you want to switch that variant. Via props, how can you do that? Pretty straightforward, as we saw in the slides, use the variant. You know, you need to define a scale, buttons. You can also change the name of the prop.

If you don't like the name variant, then you can call it something else. And what I'm talking about is down here on 45. You can call it something else. So yeah, that's that as well. It's a good idea to give it some default props. Why? Because then you see how I'm passing nothing here? It's still getting the primary variant, right? So it's the same as passing here variant primary. But what I'm going to do is pass secondary. So you can see that it's, yeah, let me go get the auto complete. So you can see it's working. So now I'd expect this one in a second to just change to the same as the primary one. There you go. How's it working? Once again, it's coming from the theme, right? So a little bit more of a complex theme now. I've got my spacing scale, I've dumped it in there. I've got the colors, but if you look at the API for this, the scale is buttons and I've defined two primary and secondary. So you can come in and of course you can use, you know, the predefined spacing scale as well for some other default things. So you can drive all of your defaults from here, which is cool. Yeah, that's sort of the example. And then the exercise, as you can imagine, just following on from that, have a go at doing it yourself essentially. What you want to do in this exercise is create a variant called alertStyle, add it, and then have a go for, well, let me show you over here as well. Basically, create the variants for these. You've probably seen this type of thing before. You're going to have four variants here, so like default, success, error, and warning, have a go at creating the variants for all of them, and you can do that over here in the theme. I've given you some colors, but once again, feel free to also bring in those theme colors if you want to, or add your own, that's fine, but the idea here is to like practice with doing those variants, and then in the wrap-up for this one, I'll explain a couple of the sort of different options that you have around doing this. One thing that I would call out, I suppose, as well, up front is that if you look at the docs, they have a slightly different – they're using a slightly different API for this, but you can do it both ways, but I'll explain that a little bit more in the wrap-up, just not so confusing now. What I will do for now is follow the example, try to get the variants working, but if you look at the docs, you'll be like, oh, they're doing it in a different way. Yes, there's more than one way of doing it, so we'll talk about that at the end. You can also have a look and try to implement the variants the other way as well, but like I said, we'll get into that in the end because it will make more sense. I just don't want to confuse now. Okay, someone have a question? Yeah, I had a question. I've done a lot of these examples previously, but I was just curious if you have any recommendations on how to like better manage variants? Something similar to like, at least for style components, something similar like to Stitches or vanilla extract? Where like we can compound multiple variants and it's like easier to manage them? Yeah, that's a great question. Let me have a, yeah, I don't have a particular recommendation, I suppose is the easy answer on this one. Yeah, I mean, you can certainly end up with like a lot of variants. I think this is one of the things where if you're going to do it in sort of like a vanilla way, you have to think very carefully about how you structure it. That's something we'll talk about a bit more later regarding like how you sort of structure the RFC and think about this stuff. But I would do is look for some inspiration from existing component libraries. If you look at how Chakra UI did it, for example, it's kind of a good piece of inspiration. I haven't personally used any additional things in order to compose them and kind of compound them further. So yeah, I'm sorry, it's not a super satisfying answer. Yeah, no problem, because at least from what I've seen in my experience that going off from like simple primary, secondary, it's OK, but then when you add like dark mode and then sizes and then other like disabled states or other more states that compound or override one between the other, it gets kind of hard at least doing it like in vanilla style component-ish. And I was wondering if there was something extra but, OK. But thank you. Yeah, no worries. I guess the really key thing I would say is like how, and we'll talk about this in the solution as well a little bit, but like how do you like extract all the common, you know, all of the common styles and then just like figure out the differences and then like stick to a really well-defined sort of convention with that? But yeah, it's true that it is a tricky problem if you get like too many variants. I mean, in my experience, I haven't seen, I mean, normally it doesn't get beyond like five or something, which I think is what we've got like in this example. But yeah, I mean, you certainly can get into that. I would say after a certain point, rather than writing a variant, if you have this need for flexibility, remember that you can do that with the props based styling as well. So if it's like one off you also have to consider, like should I make this a whole variant like because it's used a lot or should I just not? And then you can just sort of use the props based styling for the one off changes. There's a bit of balance I suppose to be had there. Yeah, hopefully that makes sense. Cool. All right. So that's that one. Yeah. We will do this exercise then. Please have a go. Yeah. Hopefully this one is fun. There's quite a bit to sort of discover, I guess, and play with here. So I certainly implore you to have a look at the API and the documentation. This one should be fast. The first one is designed to be get it going. Feel free to play with more. And then, yeah. Have a go at implementing the variants. Because this is the thing that, in my experience, is very likely, you know, that you sort of need to do such things. It happens quite quickly, to be honest, and this is a good way of thinking about organising it. Cool. Any other questions? OK. What I'll do, then, is create the breakout room. So we'll take, like, some.

Yeah. Like 30. Yeah, let's do like 30 minutes for this one, I think, probably reasonable. But, yeah. Just ping me if you start finishing earlier or if you have questions, ping me and I'll be happy to answer them. I will come around and visit the breakout rooms. But yeah, feel free to start and we'll meet back here in 30 or so minutes, I think. It's probably reasonable. Yeah. Maybe a little bit longer. 35-40. That's good. All right. Good. Hopefully that was fun. Yeah, just a bit of variants. Hopefully you can sort of see the power of variants. Like I was saying, I'm always kind of keen to keep these things not too complex, not too simple either, but not too complex. But you can take this quite far, basically. But anyway, let's have a quick recap then. So yeah, probably the style system wasn't so difficult. But yeah, I mean, that's what you would expect. One thing I would highlight in the style system one is that, you know, we have this question, and you probably saw this if you were looking at the docs, about whether or not to do – you can do install components, do things in-line. You could also do this inside an object. We'll see that again in a second in the variants. I'll show you what I'm talking about. But yeah, hopefully you all got on OK with this. It's pretty straightforward. Hopefully some of you also had a go with some of the other utilities that you could bring in. Because it's a lot more than just like space and color in this case.

Cool. Let's have a look at the variants because there's a bit more to talk about here. So, yeah, hopefully you got something like this on the left-hand side, well, however you chose to style it. How do we do that? I guess most simplistically, yeah, it was what we were talking about. You can import variant and then you can just define these alert variants. And we give it the scale alerts. And then if you come across to the theme, you can come here and it's going to come in, it's going to find alerts here and then it's going to look here for the different variants. And expect these to be passed as props and pick up on them. So you've got default success, error warning.

The thing that I wanted to talk about here is that we sort of have these different options. Oh, one other thing, too, of course, you need to do this sort of stuff in TypeScript. You need to create an interface for that and give it like your different options. You sort of have different options as you have a look at the docs. They do this in a different way. So this is where there's some decision making to be done, I guess. Like they recommend to do it like this. So you can use style components in this way as well, where you say style button. Fine or whatever. And then you pass it. Never argument then you can take an object. And so here this is just pure like CSS and JS, right? If you bear in mind, though, that's not like CSS like we were doing before, that's you need to use the objects syntax. I mean, it is still going to result in CSS. Right. But you need to change everything to camel case, etc. So that's just like an option. So we could also just uncommented. So you can see. I have to comment this one. So one option that we have, which probably went for based on the example, is like this. And then you put the default styles here and then you just put like this. That's fine. That's sort of the way, one way of doing it, which is great. I want to discuss actually what you think what you're into is the best way. This is the other way you could do it. It would have the same effect. It should still work. Yeah, you can see it's still working. If you do it in-line, then I guess the advantages essentially within line variances, you're defining the variants themselves in the component. So like everything's encapsulated within the component. So when you're trying to reason about that, that's kind of easier to reason about. It's variance, of course, there's a downside to it means that you can't drive that stuff on the things. But style components is a style system rather than flexible. So it does let you do both. And you probably also, sorry in the docs, but you see, if I call this now, it should still work. Hopefully so, yeah, you could totally like get rid of all of that stuff out of there and just do the whole thing inline. That's another option. And there's one more option as well. You can sort of do a mix of the two. You can also do inline with the template literal. So you can do it. You can do something like this if you want to do a mixture of both. You do that. You could put all of your, there's nothing to stop us doing this either, right? You have the backticks, all the common styles. And then of course you're just using, because we're inside a template literal, we can just use this syntax to break into JavaScript. And then you just write the variant, the inline variant stuff in JavaScript there. And then you just take all of your common styles and put them back in there. So those are kind of like the free options that we have that I wanted to just highlight. Essentially, the API like changed at some point. I've mixed feelings about it, to be honest with you, because I can kind of see advantages to both ways. But curious to hear thoughts on this. Has anybody got any? Or what do you think? Like, do you prefer the way that they're doing it here or the way that we saw in the example? What do you think? A mixture of both? Curious to hear. So, already I mentioned, Richard, it's better to keep all the style and all the variables in one place or in one theme file. When it's located in different places, you lose control of anything. It's hard to make any changes. Yeah, I agree. I mean, that's the thing that I quite like to do is kind of drive it all from one particular place, being the theme. So you can clean these up like a lot. I do think that there's something that I quite like being able to put the default. It's cool to have some of the base styles of the component here and also write them in CSS like I can see the utility of doing that. But yeah, honestly, the way that I've often done it in the past is like I really like to drive it from one place because then you have a single source of truth.

So then you can start to do stuff like, OK, well, I have these common alert styles. Fine, whatever. I can do this. Right. It's just JavaScript. It's just objects and tags plunked in in there. Of course, when you're doing this, you're back into the the other problem that we have to look at. Of course, this is camel case, right? We're saying border radius is not border bash radius. And what's the problem with that? You might think it's a minor problem. Yes, it is a minor problem if you're a developer. I have found that this makes it slightly more tricky if you are trying to teach your designer code because they probably know CSS. But if you throw this added complication of like, oh, hey, it's a JavaScript object now, that might make it slightly harder. But, yeah, these are all the kind of trade offs, I suppose, that we have to think about when using things like this. But I think, I mean, overall, these are just like APIs, right? You can implement the API whichever way you want. You can use the legacy one as well. They don't stop you, as you can see here. And, in fact, in the documentation, what we were just talking about is kind of covered here. I know this whole thing with two different APIs is a bit, you know, but once you get to this stage, I think, with components and theming, it's like we have lots of different options. We have to make decisions. And that's what we're going to talk about in a second, of the planning, how to do a component library. Yes, I think you had a question as well.

Yeah. I just wanted to say that there is other side of the coin. So all these variants they are component specific and unless we are like, in the example of the theme file, which we use, we store some colors and some JavaScript variables. So if we are using this JavaScript variables, I don't know in which example, but there was like some variables that I used in variants. Unless we use the same colors, the same spaces and so on. So it's like it simplifies when you store variants in components like debugging of this component so we use this various, they are related to bot and then we all look in how that variants are used in the bottom. Yeah, definitely. I mean, I agree. It's like a matter of choice if any one in the team likes inline variants then why not using them if it simplifies the development. Yeah, exactly. That's the thing. So we have to make the decision as a team. Ultimately, it's like you want to do the variants inline, fine, or you want to do them kind of like this. I think there are just trade offs. The main thing is to make a decision, it's like this disagree and commit, right, where we can have a discussion about it and then we just like pick a course. Everyone agrees, everyone's aligned, and that's it. That's something that we should probably have in our documentation somewhere in Confluence, which is like, hey, this is our approach to doing this. This is how we use our theme, and this is like the sort of expectations around it. Then all of that feeds into code review. So when you start to see people mixing that up, that's when you sort of say in the PR review, we're using this convention. And I think that's where the human element comes in, but it's important. It's important to maintain whichever path you pick, just stick to it is my recommendation because I think things become messy in coding when you get all of these different things as part of the problem with the JavaScript world in general, all these different ways of doing the same thing and then it can cause us problems, especially when stuff starts to scale, right, the more people, the more that will be apparent.

Cool. That's most of the things I wanted to cover for that. So, yeah, hopefully most of you I think maybe we'll just skip the break. Hopefully you managed to get a little bit of a break in between, but I'll just finish the slides and then feel free to take a break with the last exercise.

So the last one I just wanted to talk about a couple of things here, considerations about how would we go about kind of planning a component library. So I think generally speaking when we've seen we've already touched on some of these things, but it's super important to try to create these generic, I'm going to just turn on the light, these generic interfaces. Creating components in Storybook could really help with this. I know we didn't talk about this in here, but I'm sure you'll probably you've all heard of it and familiar with it. You can also use a tool like Chromatic to really quickly. I think some of the Storybook maintainers you cited, it would just give you like a hosted storybook, like out of the box. That's also really cool, right? Because then with that, you can, it's a really good space to not only do the dev work and sort of collaborate with other developers, but also your non-technical stakeholders can go and see what you're up to. Your designers can also go and see as well. You can actually, what I used to do when I mentioned before that I would try to teach the designers to code, I would have them play around with the components like in Storybook, essentially. Because you just you can sandbox it. It's totally isolated. It's easier to reason about that something that, you know, after an hour or so they're going to get the hang of how to sort of like, you know, do some coding over there, at least the styling, right? When I say coding, so that's great. I think it's a really powerful tool. So there's that when you're building a component library.

And the second thing that I want to talk about now is like write an RFC. I will there's a template that I really like for building, making RFCs is this one here. Again, all of the links are in the GitHub repository at the bottom of the readme. You've got like all of these different links of things I've been mentioning. But, yeah, create an RFC. This is a bit of, you know, engineering management type stuff, but we we work and deliver software and teams like we're not often solo developers. So we shouldn't really just go ahead and implement it's better to plan stuff up front. It will help you later, honestly. And yeah, that will help you with getting feedback and comments. You can also like have your designer way into that. I would definitely use that template. I'll talk about the key things that should go in it in just a moment as well. But what I would recommend in the RFC is establish a minimal approach to take within the projects and then do this thing we just mentioned. Right. Like have a discussion, not too long. Disagree and commit like you can have you can have different opinions. But at the end of the day, everyone needs to commit and kind of go for that. I think you had a question.

Yeah, Richard, is RFC some kind of architecture design document? Yes, exactly. So an RFC, sorry I skimmed over it quite quickly. So an RFC is a request for comments. So essentially you might have heard of this concept before where there's like an open RFC. So, you know, Hooks in React started as an open RFC. It was like, you know, things like that. It's like, hey, what do you think of this? Should we introduce this big change like in the library? And you're just basically asking in the open source world when you do an open RFC, you're asking like everyone the whole community. When you do this inside a company context, you're just asking like your colleagues. Right. So it's a smaller version of the same thing, but it's very, very good for getting people aligned. And it's good to have like a living document where people can come in and they can like comment on what your proposed changes are. What are the limitations of things? So, yeah, this is a template I quite like to use, like basic stuff. You just write it out. And then you put overview. Like, why would you want people to know? Goals and non-goals, background and motivation. Like, you know, what are the architecture diagrams, process diagrams? So we do this for system design changes as well. Timeline, although sometimes I sort of get rid of that one. I'm not super fond of timelines. What dependencies are there? What alternatives have you considered? Yeah. And so one person would maybe take the lead on writing such a document, and then you would share it with everyone and you would ask them to comment and probably have like a call to go through those comments and discuss it. And then at that point, take a decision. So to go into this more detail, like one of the really key things that I think you should have in your RFC. In this case, it's like the background. Why now, right? So what we talked about before, in the case of, you know, like building your own component library, you should have a good reason for this. Like, why are you doing it now? Or is that like a premature abstraction? Like, you should open that to challenge, really. What's driving the change? Like, what is the pain point that it's really going to, um, is there a big enough pain to do this thing and to fix it? Is, is the proposed solution a good one? And then you can bring into that background, methodologies like atomic design that we talked about, look at other component libraries which are out there for sort of inspiration. I would also like be linking in those. And then inside the proposal itself, the practicalities, like, how do we do the theme, right? Some of the questions that some of you asked during this presentation, like, the specification, how is that organized? Like, how are we going to name our colors? Like, all of these things, I would put them in there and agree them upfront. Because this upfront planning, really helpful. Also, you know, the TypeScript module declaration, the variant stuff, how we're going to organize it. All the typing as well. Like, how do we deal with TypeScript in here? This is a good place to put it, actually. And often with an RFC people build, like, a little proof of concept as well. At least that's how I've done it previously.

Or, like, it's a fun task, if you have the proof of concept. And then, yeah, some key components that you might go for first, what would the folder structure be? Because this would necessitate a folder structure change, probably. Considerations around legacy. Like, what's the approach? So what if you have a legacy theme? And this is something actually my previous role we faced into. It was like, there was already a theme, but, like, some developers were not using any of the values from it. Some were, so there were components that were just ad hoc spacing, and then there were some coming from the theme. There were some colors coming from the theme, but there was also ad hoc colors. And it was like a mess, but it's like, well, if there's already one, how are you going to deal with the legacy one? There's actually a way, by the way, in TypeScript, when someone's trying to use a legacy one, it has, like, an app deprecated, and it will just flag it to you. So that's sort of the option we went with, because you don't… When you're, like, working on a project, where you need to keep delivering while you're doing this, in an ideal world, you would sort of stop, right? And refactor, and just all the existing components, you just use the new theme, and that's wonderful. Okay, but you probably don't have time to do that. That's why you need these types of strategies that I'm talking about, where it's like, everything new, we're going to drive that from the theme, we're going to use the new component library, we're going to build new components maybe even as we go through the component library. But everything legacy, we're not going to get around to refactoring that all in one go. But if we touch it, maybe we refactor later, right? This kind of thing. Yeah, and then pros and cons, open questions to resolve, and the abandoned ideas. That's it. Those are the really key things that I think an RFC should cover. I would highly recommend doing it. Definitely. Because there's just so many, and you've seen during this exercise it almost raises more questions, right? About all of this stuff, and this is where we need to align with our colleagues, because this stuff is always a collaborative task, and especially where we're operating in this intersection as well, between dev and design, the collaboration is really key if it's going to be successful. Otherwise, it can be quite frictional. Any questions about any of that? Hopefully it makes sense. Do we have some example of this pre-filled RFC document? Like a completed one? A completed one. Yeah, to make inspiration from. Yeah. Let me see. I was actually thinking about adding on to a slide. The problem is that the one from the company I was just working, I can't really share it. Right. It's kind of proprietary or whatever. Let me see if I can make a modified example and I'll put it in the Discord channel. Yeah, it would be great. I agreed, it would be useful for sure. It's just a shame the last one I did. I'm not really allowed to share. It's just that. Cool, but yeah, recommends giving it a go. And what I would say that is to have a look at the you can probably find some open RFCs. But just generally how to write them like the ones in the open source community. But specifically for a component library, I'll see if I can modify it a bit and I'm paying it over on the Discord channel. OK, cool. So basically at this stage with the stuff that we've seen, we kind of have all of the basics for a deployable component library. Some remaining tasks that we might have like we should kind of think about like the plan for usage in the package by adding this as property. Components are this. You saw that in one of the first examples. I think it was over here in style components. They have this isomorphic prop called as you can have a look at it. But essentially what it does is just means that the underlying component, the underlying sort of thing that's rendered in the DOM is going to be like a button, even though this is like a style biv. That's kind of super useful, right? Because essentially it just means that you can switch what has been rendered at run time. So when components like links and buttons are all styled the same way. But you want them to be links and buttons. This is cool because you can just like use that. But anyway, it's something to think about if you're doing a component library. Another thing you need to do, I guess, is like add roll up and deploy it as an MPM packet. You could do this, but you probably won't. Why? Probably because ROI, like the return on investment, is not super high until your company really needs to use the components across multiple projects. So, at that point, it might be useful to have it because otherwise, you're into this topic of like the mono repos, etc, etc. It's kind of cool to just deploy it on MPM and then you can use it across the whole thing. Great. That's what a company like Sainsbury's would do as well. So, but yeah, you might not get to start with until it's kind of like really useful. And you could also like host it on GitHub. You don't have to use MPM, right? You can do private MPM ones. You can also host them on GitHub. I found that before as well. But companies that have design systems, component libraries probably have already taken that step. So it's more likely that you as a developer, that you will need to abstract something on top of those existing components. That's just so much more likely to be your situation, to be honest, unless you're sort of like the solutions architect at the front of that organisation. And it's a growth company. That's the one I can see where it's like, OK, maybe then it's your job to do it. Otherwise, probably not.

Yeah. Go for the question. Yeah, this question is not related to the slide, but to your quote, like, to the box component. I have a question. Do we like it's like some kind of almighty component which can be used, like, in many places. And there is no like a purpose for that component. And there is a risk. Like, when do we need like do we need to use box component? What what is like the like the reasons to use it? It's like a temporary component for some, like, some component which was not like which doesn't exist in design component or designers didn't like create finished designs of it. What is your opinion on that? Yeah, that's a good question. So the way that I think about the box is it's almost like a primitive, right in a component library. It's the most primitive components like a div right when we want to do some like layout in web like we're always using div. So I'm you know and then you can see that here right under the hood this box that I've created. It is a div, but it's a div that you might start sort of adding different attributes to using style components and style systems. I think in it was in this one. Yeah, same thing. So now it's like a powerful div, why is that cool? Well essentially you can get rid of this wrapper right. Because this wrapper here is adding like 40 pics padding. Well that's silly. I don't need that anymore right. Because why because quite simply if I want a padding you know if I want padding I can have it here, with this P already adding padding. So in that way like the box you know there's a div. There's something else here though as well which is the like you can extend everything else from the box because if you say all the box has like, all of these like base utilities that I'm gonna use. Like for my style system and then that's referencing stuff in the theme. That's great you can actually then all other components that you make. You know when you make a button or something that literally becomes like a style box right. And what I mean by a style box is you know you can also do this. You can import the box if this is now a button. And you could do that and now you're going to get all of those as well. Like you're going to get all of the utilities and now you can just like, you know abstract there and build on top of that. So that's kind of the way that I would reason about the box I guess. It's just the base, primitives that you can't extend everything else out from if you choose to take that approach. Yeah, does that make sense. Cool. I think I've broken this now.

Yeah, that makes sense. I think the other thing I would say regarding the boxes is a very cool. Where is it on here somewhere. There's a thing where it's like maybe it's over here. Guides here. Yes, this build the box. I would highly recommend this. So this is like building up from the absolute, from absolute zero. And we basically seen it in this, the exercises as well. But it's what we're talking about. Like, you can create some real base styles in the box and then you can start bringing in the style props and then you can start extending everything out. And when you write the RFC, this is 100% where you would start as well. You know, when I said list the key components, the box is going to be one of them, for sure. It's like this is your sort of default component. This is how it can be used. And then you can just document the whole thing. Yeah. And maybe it has some, you know, you can bring in. There's these other style utilities like flexbox as well. You can just do all sorts of things with this. That's why it's kind of quite powerful. And you can extend it. It's got the CSS prop. There's all sorts of things. So I think the style system utils, when you're building a component library, this is the kind of thing that is super useful. And that's where Shukra uses it, which we'll see in a second. Cool.

So, yeah, regarding this, as I was saying, you probably won't, but you know, roll up is just another module. It's like webpack, except for packages. So I've put a link in the GitHub repo again about a decent tutorial for how to do this if you're interested in how to do such things. Yeah. It's definitely fun. I mean, you could also just publish your own little component library as an exercise. Chances of doing it on the job, though, as I said, probably not massively high, but it's worth knowing how to do those things. Yeah. Package creation is always a fun thing. I personally have done it more for stuff like custom hooks, both on npm and internally in companies. It's like where you've got some custom hook that you want to share across different code bases, a bit of reusable component logic, that's where I found more utility. But, hey, I mean, eventually, the stuff ends up in the package, and, of course, component libraries are no exception. Cool.

Let's talk a little bit about Chakra, and then I'll let you do the exercise because we've got about half an hour and a bit left. So, Chakra implements a styled system, as you may have already seen. It also implements a sensible default theme using styled system theme specification. I'll show you what I mean over here. So, yeah, as you can see, they literally use the same theme specifications we've just been using. So it should be really easy to reason about Chakra now on, like, how to use it. This is something you could get some inspiration from, as well, speaking of that RFC. How did they do it with this stuff? This is their default theme. You can see there's quite a lot of things. So, you know, you can do, like, you know, blue.900 in the actual text itself. So it kind of looks something like this. You know, under the hood, this is how the theme is sort of working. So this is what a more fully featured one looks like. So you've got all of those different font sizes. They're using REMs. Good for them. Because, yeah, we should definitely in web be using, like, REMs and Ms by the way because, of course, they're relative. If you're working in React Native, you will have to stick with pixels. But, yeah, mobile is different. So, yeah, you can put all of that stuff in, and you can define spacing like this, as well. So there's sort of different ways of doing it. What else about Chakra? If you go to the Getting Started, you can see over here it's just a very good kind of set of components that you can really easily customize. Git Nation seem to think so, as well, who of course organize the conference that I'm doing this workshop for right now for most impactful community project. But, yeah, I would say it's just one of the ones that if I'm doing a side project, this is probably what I'll put it together with. And, in fact, this whole exercise here, this project itself is put together with it. So if you look in the app TSX file, you can see my computer is having problems loading it. But, yeah, you can see I built this using Shag4UI because it just means I can do stuff like this really fast, right? Like look, I just put my margins, my spacing, a line and I can use all of these out-of-the-box components. Very composable, also has good accessibility, has a good community around it, has a really good dev experience. There you go. Cool, so what do we want to do with Shag4? Let's have a look.

So I pulled it down the bottom, Shag4 example here. So this one and this is what I was saying before that you probably can start with one component library that's easy to extend and theme. And then you can, you know, take a decision whether to totally, like, make your own. So what we're looking at now is this example that they built here just with some sort of Airbnb card or whatever. As you can see, there's quite a lot of props-based styling. Sometimes whenever I'm talking about this, like, internally in companies, I've had this reaction where it's like, oh, that's really nasty having all of that. But of course, you know how to use the theme now, so we can get away from that by driving all of this stuff from the theme and having a decent set of defaults. You can override the defaults for any of these components to the Exposure as well. So if these are your defaults for the Text component, then, yeah, what I would recommend is abstract it, what we talked about, and put those defaults in there. And then, you know, any you should only really be using this sort of props-based styling in a code base for when it's like a one-off case, right? Where it's like, okay, the margin left is 2 in this case. It's not always 2. That's the case that you should use it for. Anything else, I would say, you know, if I see stuff like this, it's like, well, you know, it's repetition. If you see it like more than twice or three times, then think about what your base styles are doing, like what's the base style for the Text component, for example, in this case. Hopefully that makes sense. The reason I'm saying all of this is just, yeah, I suggest ShareCode sometimes and people are like, oh, this is terrible. But it's super easy to overwrite. So that's the answers, actually. So what is your challenge here? Let me just go back on the right branch. One second. Stash the changes. Ok. So essentially your challenge with this one, which hopefully will be quite straightforward as well, but it's a good chance to play around with Chakra, is, yeah, you can just have a look at how to extend the theme in theme.ts, right? Because when you install Chakra you won't have, you're just using that default theme that we just saw. But have a go at bringing in our brand colours and apply those to the design. So why not have a go at changing that background of the badge on line 21? That should be this here. See it's got a grey background? Try to get that background to use one of those brand colours that we saw before, like the mint green or something like that. That's kind of the main thing, and then as a bonus have a go at overriding the Chakra Component with some custom styles. They talk about how to do this as well, that's what I was just talking about. This text component, for example, how would you overwrite that? With some, you know, your custom styles and create new defaults. You'll have to have a quick look at the docs for the bonus. But yeah, for the first part, I think this is the really key part. If you're a Chakra provider but you haven't got the theme or anything yet, and in the theme TSX over here, you've got like, not a lot. Have a go, have a look at the documentation. Try to get that going. And yeah, I guess I will give you like 15 minutes and then we'll come back and have a quick look at the answers. And yeah, while you're at it, have a play with this because the cool thing about Chakra is it's implementing all the stuff we just learned. Like all the style system things, have fun with that, have a play around see what you can do with this. And yeah, have a go at bringing in those custom styles and hopefully you will see how we could just build on top of this component library as a quick way of doing it, but also you can see how we would go about building our own. Because style system is exactly what they used. I think they're using Emotion rather than style components for the CSS and JS library but the API between that and style component is the same. So they're using essentially style components or similar and style system in order to build this whole component library which is a very decent open source project. Any questions about this one? Nope? Cool. I think there's like less of us now, so I guess we can just stay in the main room, so I'll just I'll be here. I'll just probably turn off the camera and go but please ask me any questions. I'm just going to go and get some more water, but I'll be here in like five minutes onwards, so just shout if you need any help with anything. Yeah, and good luck with this final exercise. Cool, how's it going? Good, thank you. Good. Did you get it going? Hopefully yes. Hopefully yes. Hopefully yes. All right, let's have a quick wrap up, just to show you quickly how this might be done. I mean, hopefully it was a pretty straightforward exercise. I know it was a little bit of looking at the docs, but as you can see, Track was a really good way to rapidly pull together UI, and yeah, it really highlights, I think, the power of this approach, right? of using style system, so that we can do props-based styling, but also we can have that driven from a theme. So we talked already about Chakra's default theme, so, of course, all of this stuff relies on their default theme, so when it goes for, like, you know, the colours and things, it's going to their colours, of which are quite kind of extensive. So, if we got to the theme, let's see, oh, wasn't this one? I think it was this one. Well, anyway, never mind, let me just show you the solution quickly. So, yeah, all you needed to do in order to extend it, so you're extending on top of the default thing that they implement in the documentation, which apparently I've lost the link to now. Yeah, how do we do this with our legacy style? So, again, we pulled in these brand colors. These are the ones, remember, right at the beginning that we, like, exported, were in those sass files, exported them in JavaScript variables, and those are in our brand colors, and now I can use our brand colors, right, directly in Chakra. So it's a pretty quick way to get going with some legacy stuff that you've got, and then, you know, you can start using this component library. What does that allow me to do? Well, here, in the background, now I can say brand, so it's going to go find that key brand over here inside colors, and then it's going to take, like, all of these brand colors, so, in this particular case, I've gone for this robin's eggs, so that is why it has resulted in, yeah, that green color. But we could also do, let's try a different one. So there's something called, well, let's see. What do we have in here? Type script once to load. What was a shy one? Shy moment, let's try that. So I think that's some sort of purple color or something, and yeah, we should see an update over here in a second. Go get that one. Yep, there you go. Make sense? So now we've just pulled in all of our existing brand colors, and we can use all of these style-based props.

So for the background, whatever, again, the abstract components, right? Like, if I was using this, I would have abstracted that badge component, and inside my abstraction of it, I would do like import Shakra badge as Shakra badge from Shakra up here in a different file called badge, and then probably, if I want the background to be this default background color, fine. Then I export it, and I just use badge. That's where I would start with these things, because like I said before, you're sort of planning for change, right? And you could even, if you want, you can also just give it the default props, but everything is driven from a theme, so you can use variants here as well, like you could pass a variant, you could define that variant in an extension of the standards theme, etc, etc. And then as an override, yeah, you will have had to have gone and looked at the documentation for this, but, you know, you can override all of the default styles that are there with your own variants, with your own stuff, with your own defaults. So it's like basically fully customized. Oh, there's the theme. It's always when you're speaking and looking for something at the same time, you can't find it, but this is what we were looking at before, right? The default theme, so you can find all of this stuff is just available to us out of the box in terms of colouring. It's very reasonable default theme. Colouring, font weights and sizes, everything. But yeah, what I would do is implement it, start extending it, make sure to make the abstraction just in case you want to move away from it or make your own later. Yeah, and it's already under the hoods implementing all the things that we saw in this presentation, so it should be easy to reason about. They have a very good section as well, comparing this component library to other ones, like what are the different trade-offs between other stuff like using Tailwind CSS for example instead, using other component libraries like the MUI, the one based on Google's material design, like what are the differences? I've also linked that in the readings, but yeah, I highly recommend checking that out. I would say, overall, yeah, if I was going to pick a component library to use and it was someone else's, would definitely be this one, and I've built my own several times, but like I said, most of the time it's a case of building on top of it's those abstractions like bringing in this stuff, integrating legacy, and building small abstractions that are helping you develop the UI faster using these tools, on top of what's already existing because like a company like Sainsbury's you already have the component library, but you might need to modify those components, so you're going to take those steps and approaches. Yeah, but hopefully that's helpful, and if you're ever in the position where you get to build your own, and that's a good time to do in a company that's also super fun task to do, start with the RFC is what I would say. And yeah, any questions or comments about this one, or anything else?

I have one question, Richard, do you know so like any like possibilities to automate, for example if we have Figma's design, automate the creating of the components, maybe some plugins in Figma. This is something that I would like to investigate, but I didn't have the chance to do it. Maybe you have some great advices.

Yeah, that's a great question. I think there are some tools, actually, and I suspect that Figma are probably working on something with this themselves. I'll tell you who I do know who's doing it. It is the AWS Amplifier, whatever it's called. That suite of tools helps you do this kind of thing. Taking stuff from Figma. And they're using AI to do that basically, right? Taking designs out of Figma, and then building a bunch of React components essentially for you, so you're not starting from zero. And then from there you can fully customize, fully modify those React components which are already based on this. So, that actually gets you kind of a long way. Probably what that doesn't do, I haven't played with it that much but I have seen the demo of this, it probably isn't gonna do your whole theme for you, right? You're gonna have to do the at least for now, the theming and things but I suspect quite soon we'll see some tooling coming along which does that where essentially you create a design system in Figma and then you feed that and it's like creating an actual theme file for you and allowing you to then modify it from there. That'll be really cool because we wouldn't have to. Right now the interface between Figma and getting this stuff in a component library is still like there's a bit of friction, right, because that's the thing about Figma that people say it's like it's the worst design tool out there except for all the others which is to say it's not great but it's the best thing that we have but there's definitely stuff coming down the line on this. Coincidentally I've been looking into some of the things people are doing with code generation recently using like the AI stuff like the GPT-3 models and this is the kind of thing you can absolutely do and like the model would learn over time so I would expect more tooling to be coming down the pipeline but in the meantime, yeah, we'll still do this and don't worry too much about it taking over our jobs. I think I'd still say we're way off that but it's definitely going to supercharge everything you just asked. It's like how do you get from like 0 to 1 quickly with a bit less friction Yeah, hopefully that answers the question Yeah Thank you, Richard for the workshop and looking forward to a refilled RFC file template Yeah, I'll send it. If you ping me a personal message, just ping me like a hello or something on discord and I'll send something over to you I'll think of something But yeah, the same goes for everyone else Feel free to stay in touch on discord You can find me on LinkedIn, I'm not on Twitter so much, especially not since this recent takeover And obviously on Github, anywhere else just reach out. I'll be around Cool.