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

So, yeah, welcome everyone. Thanks for joining. You are in the refugee eye development in react harnessing custom component libraries and Design Systems. So yeah, thanks for joining. I think I just mentioned this for those that already heard it apologies for repeating. You've got the GitHub repository link down here at the bottom on this first slides. I would encourage you to just open that up in a browser or feel free to clone and install that in the background, but we'll have time for that also. So, um, yeah, I guess we'll start from the top. Who am I? Maybe you're wondering. Yeah, I'm Richard. Curious engineer most recently so for the development manager at Zach, which is a kind of quick Commerce company operating outside the UK pretty similar to get here and gorillas and those things but I am a free agent as of a couple of weeks ago and I have been lead developer on projects for organizations like acne magazine which Boston University when I was a partner at the ingest the JavaScript startup and coal organizer of JavaScript London meetup groups since 2016. So yeah, really like doing community things and why I'm here you probably gets that yeah. It's also train developers from a variety of companies. I used to run right just Academy with Alex laveder who's some of you may have seen speak about micro front ends at the conference. And yeah also my person learning to fly an airplane. That's one new challenge. That's me and a nice show. Let's talk about what we're gonna cover into these Workshop. So essentially we will go through an overview of science systems and we'll start then to talk about the component Library considerations a bit about CSS and Jess integrating Lexi styles of show components. Then we'll look at feeling in particularly in style components Library this concept of atomic design will then have a look into style system how that sort of works and some various aspects that we can harness for our component Library stay in particular various. It seems specification. And then also we'll talk a bit about some considerations the building and Publishing a component Library how you might want to go about doing that either inside a company or outside of one? And then finally, we'll take a look at shark for UI. I mean, you'll see some stuff about shuffle all the way through because I based the exercises on that as well as in the repository itself uses that component library, but we will see towards the end. So let's begin. Let's talk a little bit about Design Systems component libraries and theming to get started. So what is a design system and why they're useful there's a kind of I think it's useful to start with definitions that other people have given for the design system is because it's a little bit there's a few. And then I'll give you mine. Here's a couple that I like so a collection of reusable components to tie whole products together. That's what free codecam said everything that makes up your product from typography grids colors icons components coding conventions all of that stuff a design system brings together all of these in a way that allows your entire team to learn building grow. And then we also have some examples of some Design Systems often find it's easiest just to see an example. I will show you if you work at a big company. This is something that you probably have so you probably know exactly what I'm talking about. And actually I work for a while as presses big company writer has several Brands. It has like Argos and habitat and all of this stuff. So, of course they sort of have A design system. I'll show you it's over here. It's like documented so their design system is called Luna and you can sort of come in here and find things like I can come kind of find all of these nice colors. That's great. So you can sort of see everything that's documented regarding these Brands, right so you can see the other brands so they have here they would have sort of different colors. You can find everything. That's a photography the logos layout. So this is all of the stuff that kind of goes into a design system. There's also 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 a fundamentally they're just a store of value for design fundamentals such as colors or spacing and topography often and so you can get this cross platform compatibility, so Um, he might be wondering though. Like what does a design token? What does that actually mean? So a design token might you know, the token itself is called like nectar brand one for example, but we'll just start actually mean. Well, you can actually go and have a look at the code base. I think I already had it open over here. But if you have a look at developer documentation, this is where you normally get into that. But the answer to that is as you can see in the case of Sainsbury's and this is true for a lot. Um, it's like in SAS variables. That's where it's ended up. Why because it's a big company and like everybody was using right until really recently so probably this is the case. So yeah just a quicker side on that. I think that this is really interesting this concept where when we're talking about component libraries and Design Systems, we often think about the Greenfield 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. But I'm really Keen to also try to bring in this concept of like what if you work somewhere that already has one or what do you do with the Legacy things because most Often when we're working on the job. That's the situation that we face into certainly in my experience several times both as startups scale-ups and big corporations. It's like 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 I think that it's this concept of the overlap between sort of Dev stuff and ux and design stuff the design system really sits in the middle of that. So I kind of believe that it's that this intersection between Devon design and it's bringing together the design and Technical assets in a way that allows your entire team to learn building grow. So I got some inspiration from one of those others for that last part, but that's sort of the way that I like to think about it. Obviously everybody on this call. Probably it's great if some designers join us, but probably you're all web developers working and reactants. You've been a react conference. So we're sort of more focused on the website, which of course the component Library goes into that. That Circle over there and that should be a reflection essentially of the design system of the component library is based on the design system. One thing I would say is that it's super important to collaborate with our ux and design colleagues in this space primarily so that they're aware of any technical limitations when designing components because they're going to be the ones designing it. Right and we're going to be the ones implementing it but a decent component Library will necessarily be dependent on the level of collaboration. If anything that is very very difficult to do unless you're a person who you're a developer who also already has a design background as well. So you were designing and learn to code maybe in that case you could do it here, but otherwise, I think it's super super important. This overlap is always like a really key key thing in any organization that's trying to ship quality products. I think the other thing I would like to highlight I guess here is that it's a sort of joint ownership. For example, if we just find a spacing scale and the design system and Implement that in a theme then that should be respected and all the designs, right? This question of like who has ownership. I mean ultimately both but I think it's really good to have that discussion with design team like who owns this and how do we have like accountability about when it changes and who's driving those changes and things so and then lastly another thing I was going to mention is that you should also 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's kind of always best to try to avoid a premature abstraction that goes for both technical things and also like the design things and it can be a bit of a premature abstraction to already like create a whole design system. I guess it all sort of depends on how you want to rationalize this but maybe a key. Okay after me would be if you are. If the need if you have this need for sort of like something that's used across multiple teams working on multiple projects and there needs to be like a unified look and feel to all of that. That's where for sure. It's gonna really really help you right before that. There's probably other ways to do it like you could extend an existing design system that has some decent like defaults. We'll talk about that later in the presentation and you could also the same goes for the component Library. So yes, we can do everything like from the ground up. Should we it depends right? Not a super satisfying answering. Nobody 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% custom. But of course you lose a slight amount of configurability. That's okay. Anyway, yeah, that's what I'd make that side point so I guess that brings us to the component libraries we're developers. So we're going to talk about the components that Library side of this in the design system. So what is a component Library when it's a home? Does anyone want to answer this question? I guess I'll throw this one out of there group if anyone wants to go for a definition. You know, it's like breakage. I don't know microphone dance or something. That's can be shared. Like it's a group of components some Styles like style system that can be reused like in different apps like in like company in order to share like the same like design so we shouldn't be implemented from scratch time. Yeah, yeah good good answer exactly. So essentially it's as we were saying sits on that technical side of this sort of design system as sort of a reflection of the design system and it's implementing sort of the code from the design specification in a reusable and extensible way. So these component-based architectures all of us work with libraries based on component-based architectures. Now, I mean, you know react angular the like all of these component-based architectures because it's really good for reusability and extensibility. And yeah, that's our default approach. So this is where a component Library comes in and it's super useful to have one because of course, then you can build multiple products with the same base set of components. So it's essentially a way that we can bring uniformly seeing like speed up the development of user interfaces cool. So you probably have heard of some of these already, but just to recap it. So some popular component Library shocker you buy we'll see this one later on. Favorite for developers. I'm definitely it's really good. I really like it for lots of different reasons. But yeah, I'll save it for later. You've also got material design. There's a component react component Library based on material design, which was Google's 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'd put the classic bootstrap on here as well. So somebody 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 like, you know, I guess it was kind of maybe 2013 through to 2016 2015 2016 before react and sort of component libraries in general were popular like bootstrap was just everywhere. That was the thing anyway, Um better history. So yeah, let's talk a little bit quickly about CSS in JS. So speaking of History. This is not a New Concept this started in 2015 and it was made possible by the updates to the JavaScript library that came with es6 essentially. So hopefully all aware of these kind of libraries these CSS and GS libraries such as stock components and emotion. But yeah, you probably already know the benefits, but we'll just talk about it very very briefly to recap. So essentially gives us full CSS functionality, but Within JavaScript, it uses types template literals to achieve that which was a feature of your six. That's how it works. I've Linked In the Documentation if you go to the on the GitHub repository at the bottom, you have a bunch of links. I've linked the original blog post about how this works that maxloader wrote who created style components. So do recommend giving that a read it's also there's another thing about how they use Tag template literals now, but anyway, very very interesting use of new JavaScript features. Well, not new anymore, but you know was super funny event and I still like it. But yeah, it's this idea that essentially you kind of can do style the bottom. It's like calling a function with those backticks. We will see it in the code in a second. Yeah, 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 that I've heard in the community. People are talking about like not doing CSS. Ingest anymore was kind of going back to using CSS. It's always an option right? There are no definitive like answers to What's better. We can always assess but any for the purposes of this presentation, I think we'll assume that we're going to go ahead and use our components as a library. So therefore we are writing JavaScript essentially like we're writing CSS But ultimately what's happening on the hood is under the hood is that is Javascript. Cool, so I want to talk a little bit about what happens when you have a legacy code base then with like a bunch of styling. So you may have worked in places where you see things such as this so you have some you know, they none react components. So what I mean by that is just standard like jsx components like the Divine H2, and you have a bunch of like class names. Um, how can you move away or how can you move sort of towards CSS? Njs? So if you're using style components essentially like this is pretty straightforward. Hopefully everybody on the course familiar with this so you see the chat bar wrapper component. You would just be like, okay, that's now style.this. I use the bactics the tech template literal is gonna do The Styling in there. So yeah, you can do that. That's pretty straightforward, but you might be thinking what if I want to sort of keep some Legacy Stiles This is something as well that it's kind of overlooked a little bit. It's quite simple though. Um, there's this trainable methods in style components of this stock attrs like the attributes. Um, and you can just use that it's the first and only argument of an object that will be merged into the rest of the component's props. It does quite a bit more actually than just this so I do recommend having the documentation which is linked here, but One thing I would say with this as well. If you're gonna do this, it's a little bit messy. You need to Bear the specificity of 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 like component first. So everything written here, for example, if I've got you know that border bottom here anything that's in that class name. It's gonna be overwritten by that. So just bear that in mind. Normally, it's not you want to try to avoid as much as possible. You know competing Styles because that's where we get into this mess where everyone starts to put the important, you know, the explanation mark in front and things we want to try to avoid that. So I'd avoid as much as possible. But you know, you can face into circumstances where you just need to you need to do that and you want to have some flexibility. So yeah, you can do things like this. Cool, just before I show you the codes. I just wanted to give a quick aside as well about abstract components and just making a small abstraction up front. So. I would highly recommend this. This is just something from my experience and I've done this a few times now actually in a few different places companies are different sizes is often overlooked, but it can cause you issues down the line. If you're using a pre-existing component Library would highly recommend that in your project in order to plan for change. You just make a small abstraction which can be as simple as make any file import the button as like whatever the component Library button is. So, I don't know if it's from Nui. You could call it Nui button. And then simply export it again. Why would you do this? Well, essentially it just means that if you need to make changes which probably will down the line. You just do it all in one place right quite quickly code bases. If you start importing things directly from the component library that can be fine to start with but then you what you'll find over time often is like people make slight adjustments to these things in a ton of different files and that can be really hard to unpick later. So it's just kind of planning for change in some ways. You might be thinking about supremature abstraction. Yeah, but it's 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 where you would just come here right now, if you're using I don't know like the chakra button or the mui button anymore. Will you just come here and you just swap it out and that's fine. You could even use more than one component. I wouldn't recommend that but you could use more than one, you know component Library will just take effects across your entire application because we'll just be broadcast. So yeah something to consider I think as well, I would note here that if you're starting from scratch, this is essentially the same thing you would do anyway, right in terms your code structure. You would have like components you would like to find your own button. So yeah, if you're using someone else's component Library, we'll do that to you and I just put a small example here often how these things in style components get extended so you can just pass. A component essentially just gets pastors a function argument styled and then yeah, you can overwrite styles on top of that in the normal way. cool Hopefully that'll make sense. And yeah another really good trick for Integrating Legacy Styles is that you can actually export SAS variables as JavaScript variables and then you can just use some directly. This is really overlooked as well often people run into this situation where they're like, well, I want to start components or emotion or whatever in this Legacy code base that I'm on but I need to use the SAS variables like that's needed where you can actually do this and I've actually got a little example in the code, which I'll show you in a second of how to do it. It's super simple. But again often overlooked this is something that I'm projects might work and Sainsbury's I did you have to go on maybe a little bit of a hunt but ultimately actually as we saw in the design system, like there's gonna be in a big company some SAS variables which are used to styling and that's gonna be stuff like the brand colors and you can probably find those and that's really really good. Right 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 or whatever but you want to keep pointing at the same place in case somebody tomorrow comes along at a high level and says, well, we're changing that color because you know, it clashes with another color 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 realize for quite a while and the whole point of these Design Systems is like bringing, um, bringing sort of uniformity across across all of the different products. So yeah, and also, yeah, you can fully adopt CSS this way in a new project. So yeah, it's cool. All right, let's have a look at the code. Does anybody have any questions about anything? I just said before we have a quick look at this coding stuff. It's great. So I'm gonna do a quick demo for this one and then I'm gonna stop talking and we're gonna do an exercise. So I always aiming not to talk for longer than sort of like 35 40 minutes maximum before letting me just encoding so 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, they're 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 the your exercises 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 up in new message as well and I explain a little bit here about the folder structure Etc that we're going to look at so I won't repeat that now, but essentially it looks like this is very simple. Each exercise has like a heading everything is separated into example and exercise. So I'll be showing the example stuff and then you'll be doing exercise. 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 have 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? We've got this Legacy. It probably won't be called Legacy Styles. It's probably whatever the base Foundation. Yes. But anyway, we have some stats that's been imported right? It's in the project. Um, and I can show it to you over here. So what does that look like? It's a very basic a success 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 often times. You will see exactly that like it has sort of a fun name, right? Well, do these variables look like like this? It will probably be a little bit more convoluted right on a big scale. But obviously I've I'm 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 go. Then 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 mostly found them? I created this export folder where simply you just import all of them import the existing SAS 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 they are like you can see them all. And we can actually go ahead and use them you might be wondering about the typescript. 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 this package called type CSS modules, which will help you do that. But to be honest with you can actually do it as you go through if they don't have types already. It might be useful to do it like iteratively and sort of do it yourself. But yeah, if not, you can also gem them or if they're liable to change might be a good idea to also general actually as well. So things to consider Um, okay. So let's go back here. So let's also have a look at this attrs thing that we saw. So yeah, we can essentially do this. That's it object. And now in here, I'm going to pass it. This class name. And I'm going to give it that box. Okay. 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 then if you can see, but essentially it's just giving it like a border is 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 down the presentation to spare reminder specificity, right? So like anything at 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 a 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 a good thing about his entire spiritual suggest you all the stuff you've got. But yeah, we can just use the brand color. They go it's changed the Middle East now as you can see over there on the left, hopefully. cool any questions about this part? That'll make sense. I'll take it as a yes. All right. Nice sort of Richard. I feel one question. What is the best strategy are the best approach you name me and this like this says sliding very variables. So for example for colors or like some borders, I don't know do they need to be like really related to some the part of the app some component where you use it? Yeah, I would say in this example. It's where the SAS variables already exist. 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 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 that brand colors tend to have a specific name. It's sort of what we saw over here with the Luna thing right like these these colors. I'll show you like this colors have You know, they might just be called like brand one highlight or something. They also can have let's see if I go into the Sainsbury's colors. Yeah, like orange base orange dark plant-based. 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 exist. So I wouldn't change the names of the 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 I would go about doing this and we'll go into bit of detail on towards the end as well. It's to write an RFC request for comments. So you sort of make a suggestion right? And then you ask people to weigh in who do you ask the way in the desire ux like and design leads as well other developers so that there's some consensus about naming because naming is hard I would that would be my suggestion. Yeah. Yeah, there's Question, I guess I like forgot it to answer when you've been like showing the first part of your oh is a 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 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 are from 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 gonna be the thing that's gonna 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 just 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 else's 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 with superflexible. 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 there's 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 does 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 RSC, you know picture 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 out from work right with building a component library that they're always this any change that'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, okay ours is that yeah. So anyway, like we should start like area and start our project. Having some shared Library where we like put all our like share them like common components with this like Styles, even if they whether they are like customizing some library or not. Like so like putting it in one place correctly. Exactly. Yeah making a small abstraction. So you have like some photo which is like your button you should have some button for example or like a cool deal 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 gonna make it really easy then to change in the future even to change library or to build your own on top of that. Thank you. Awesome. Cool. All right. So onwards well, we'll do an exercise in a second. But um, let me just put this back. So I'm just gonna close some of these things down so it's not too. Let's see styled components over here. Yeah. All right. I'll leave it on that one. So, um, let me know if the code isn't big enough by the way or a few 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 gonna talk about themes now, but what do you think Costa kind of having a theme? Is it so we can kind of change it as well if 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 a 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 the 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 Sigma files all 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 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 is just a plain old JavaScript object a pojo. And so how do you do that? We'll start components. Well you bring in this theme Provider from the library and then you just need to pass it like an object. So here we're literally passing an object with one key and value keeping 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 if you do this like property, it's gonna like pick up this medium series for example, and you can see that in the documentation over there and I will show you in a second as well. Um 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 regarding like a light theme or like 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 already is normally has already been implemented to be honest and some good component libraries will already have that and you can do some tricks like sort of inviting the color but I'll show you how to do it in a moment. Um, but you 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. It's that like you have a variation on the same thing. So you have one theme but you need you know, you have a primary type button and a secondary type button that that's very very common. But anyway that said 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 gonna be You just pass the results of that to the theme and you're gonna get the gonna 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 second like this. Yeah. This one actually is the one on the left. So it's super simple can be as simple as this so colors and then you can 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 ingesting comes back again as well as 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 gonna be camel case, you know, like if you have some sort of And justify content Center or something like that like the justify content. It's not gonna be a dash. It's gonna be camel case. Anyway, just something to bear in mind. But yeah 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 bass. You might have some light you might have some dark and then you can switch those out between each other. that we will build up from the simple one because Generally speaking you tend to you tend to only have one. Anyway, we'll talk about in one now. So yeah also want to touch on this you can quite easily allow themes switching. It's just an object, right? So you just need to switch Which object you're passing to that theme provider one of the solutions that you'll 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 that you need to broadcast all of the components. Anyway down the tree now, obviously there's other you might have another Global State Management solution going on, right so you could also like story there, that's fine. But often this is one of the examples that you'll see quite widely something along these lines where you use context and then in the app, you know in your context you have some states and then you just decide based on that like you have a sort of map between this light and dark and then it just decides Runtime which one to use? So yeah, that's kind of how you do. I don't want 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 like this. This is kind of like a soul thing. It's funny back in when was it like in 2018? It was like yeah 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 needing to implement such a thing is not that high. It's more likely that you'll see that there'll be a product where for example, this is a use case I can see we're different users see entirely different themes that happens sometimes especially with like software as a service product where I don't know one set of users. I don't know have 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 you can also Imagine totally different brands, right the thing with Sainsbury's like as well. They have you know, the brand coloring for something like nectar is totally different from the brand coloring for Sainsbury's which is like all the orange and the nature is like 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 that you'll probably face into where it's like why I have a 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. This is something that we really almost for sure. We're face into and that's where the theme park and also help us. Yeah. I think that's a question. Yeah, so Richard do we need to like add premature theming or we we shouldn't create semen unless we have a case for that. I think it's good some I think 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 tree, right? So as soon as you using style Companions and you've got some colors in the application instead of having that sort of spreads all around and you've got these sort of like different hex codes and different places. You have that in one place. That's the real I think power with having the theme so everything should just reference that and as we saw before that's really easy to reference that you are components. So if nothing else I will do it for that for sure and if like If we can use CSS again, we like like for the first version ucss variables just to store needed like sequences as variables and when there is a need for like different themes then we can use something like other for that. Well, you can actually the thing that you can do is you can if you have those SAS variables hanging around you can bring those into the theme and then everything is driven from the theme everything in the application because bear in mind that you think stop components every single and has access to that theme object. It's like something good. So it's very powerful for you know, your source of truth of 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 using the same thing and then if that changes because you'll design that tomorrow says, oh I need to change the shade of the 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 you now, you'll see you'll see the power of this I think now hopefully it will be in the exercise there. So let's do some theming. Let me show you the example quickly and then I'm going to get you're gonna get to do some coding because I think talking about a look at 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 we're just trying to build up right so maybe for some of you like our this is super simple. It's too simple. I that's true, but we'll be building up 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 as you can see when I like hover on it goes green. It's like blue and then the screen 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, right so I can say here like props.themed or colors.blue. You know, you can also do stuff by the way like, I mean, this is not really related just JavaScript stuff, right, but you can do your destructuring in 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's it. You can see that it's like getting the stuff from the theme right? So this property colors blue is pointing out the blue in our theme over here. So it's displayed 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 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's sort of lowers the cognitive load right because I don't know what blue means exactly I could be any type of color blue. Yeah. Hopefully that makes sense. So you can see there's also like a wrapper component here. I'm also using the I'm just using the background color, which is that like light color there. You can also have a play with this and then yeah here I'm just passing the theme objects as we talked about. There's something here to the I was gonna mention which is that you can Make use of typescripts type interface for the theme object the way that you do that generally speaking is like you just declare stock 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 structure is going to complain probably about a bunch of about the other files because some more theme here that's like sort of a theme in every folder but essentially as you can imagine that's now giving you you know, 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 guys complaining of course, which is kind of to be expected. But if you're doing it for real, I would actually 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 as typescript off in this 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 prove that. That it should change. So now I'd expect. Yes to change color. They go the color changed the green. Cool. All right. Let's have a look at the exercise. Is there any questions before we have a quick look at what I want you guys to do? Nope. Okay, let's do it. Um, so if you open up steaming and the exercise folder And the other thing I would do is open up the readme and this is the first one so yeah feeling open up exercise. So your task here is kind of to implement the themes. Yes, so I've put some code 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 from style components, then create a simple theme like whatever you want. I would recommend having some colors Maybe. So I've given you you know over here maybe have some colors you can have whatever you want. And then yeah implement the colors 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 colors 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 colors. We'll do this in their recap. I'll show you how to do it. But remember what I mentioned you can actually import if you think about it in this file, I could import those SAS variables, which I created the JavaScript export for like their JavaScript variables so I could get those colors going here, right? That's kind of cool. So yeah, that's a little bit of a bonus task for those, you know, it's 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 you style systems are sort of give it a few more super powers. So yeah any questions about the exercise before we start how what I'll do by the way, it's I'll create breakout rooms automatically assign all of you to those probably like five or so people per breakout room you compare programming together or 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 the busy. I might not 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 highly recommend having 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. Okay seems like there's not any questions but if anything, yeah, 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 In the chat as well. I'll respond to the things in the chat while the exercise is going on, too. I think that I'm yeah, sorry. I haven't responded to those yet. cool Okay, let's do a quick recap. We're gonna do something more complex in a second. So I hope you're feeling feeling good and warmed up from that. Yeah, hopefully was pretty straightforward. Let's give it a quick. Can you see my screen? Yes, so I've checking. Um, yes, so essentially yeah, we can implement the theme I implemented like the bonus I was telling you about so pulling 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, mainly and we should also see that pop up. So really the key takeaway here is yeah. This is how to implement feeling in style components. There's nothing much to it. To be honest with you. It's an objects. Hopefully you got the chance to sort of play around and get used to it. How it sort of works and hopefully some of you maybe even got the typescript going as well. I've got the Legacy Styles going to so that's sort of basic feeling and how you can start to use theme files. Any questions about any of this all making sense so far? Cool. Okay, let's move on then onwards because we got some more stuff to talk about. So we're gonna get it's gonna get more complex in a second. Although technically speaking. You know, the funny thing about theming it's like if you look at the style components dogs this in the advance 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 like extend this and what are some of the limitations so Just firstly wanted to talk a little bit about this concept of atomic design as well. This was introduced by guy called Brad Frost. I think it's pretty older. There's been around a while but it's the concept that web elements should build upon each other like atoms molecules organisms and so on again another thing that we should have a chat with our sort of lead design ux person about because they probably know about this it's more on the design side of that equation than on the left side, but I think it's quite a powerful concept so This is actually something the kind of could be a little bit hard to follow with stock components this kind of idea and we'll talk more about that in a moment. But in terms of this like, how could we reason about like, what is an atom molecule organism template and page? So if you imagine the button for example, then I guess a button element would be an atom. If you have a sort of style component button, then it's you know, it's becoming a molecule. Maybe it has some other utilities like the style system, which we'll see in a second a component ingest a button would be an organisms. So something like a motor I guess or like a kind of cool to action something like that a collection of organisms that make up an experience would be considered the template. So I tend to think of page sections here the templates like You may have I don't know the CTA cards and also an email input Etc and then templates make up a page. So yeah pretty straightforward idea. But this is quite powerful and it's easy to deviate from this believe it or not. That's the funny thing. So yeah. So this is where we're gonna talk about style system a bit. So style system is a set of utilities that can help us overcome some of the limitations with style components and essentially make it more flexible. We'll talk about those limitations now shock for you. I actually it's quite heavily on this and so the sort of several other component libraries. So just the way of making it super flexible which you will see now, it's quite a powerful tool. What are the limits of style components? What do I mean by that? Well, The thing is stock components along with a 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 Styles around time that's will start 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 a bit 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't 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 for you also want to retain the flexibility to overwrite whatever those defaults are. So you get a reasonable sort of defaults for your styling and then you also want to create a situation where the developer was kind of a dead experiencing. I guess can also just be like well in a particular case, I want to adjust it you want to be able to do both? Um, so yeah. Let's go to the next one. So in a nutshell what it starts system, it's a set of utility functions that adds style props what a style props. I mean we've been adding style props already. I mean like theme this theme is almost like a style 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, right? So it's essentially 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 fought out patterns. So it allows you to control Styles based also based on a global theme objects with typographic scales colors. I may have properties. This is something that works in tandem with CSS njs 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 wouldn't you can't Implement style system without You can't implement the utilities to be honest not without stock components unless you build your own version of that as well. So you could find a way but yeah, that's the way to think about it. And yeah, he's pretty used pretty widely in terms of increasing flexibility in off the shelf component libraries. Do we see around? Yeah, it also comes with default Theme by the way. So that's and a themes specification which both of which I highly recommend looking at the other thing is enables the use of variance, which we're gonna do talk about in a second as well. And that's very powerful. So essentially we can just do these variations which are all sort of driven. Try our team. Yeah, and that will help us cut down on our repetition in styling. Cool, so let's talk about style system. So Have a star system looks so you import these utilities and then you can see over here on the slide that if you've got these space color and layout utilities use 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 pulled out one thing. I would highlight as well is that you can decide whether to use the long form or the sort of test. So the short form as well. So this end 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 peas and EMS 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 echo 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 variance and then I'll show you the demo of the south star system in the code. That's just keep keep it in that order. Anyway, but there's the example over there. So let's quickly talk about variance first. What are the variants so you can use and by the way, you'll have any an exercise to do both for the stock components. But also sorry the style system but also the variance so the variant API is essentially used to apply complex styles to 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 import 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 but it makes sense that they change that if you think about it in some JavaScript object so key is not maybe the best name and then yeah, you can apply button style there. And now what it will do is go looking in your theme. And we'll find the buttons scale and they 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 bottom 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. They're saying like buttons. Okay cool. And then I Define the variance as being primary and secondary. So if it's primary these are the things that's gonna get if it's secondary. These are the things that's going to get so the result of that is this so you can see here in the variance example is two buttons cool So let's have a look at the codes because I know that's correct rapid, but I think that explaining it in the code at this stage is kind of easier. So I'm just gonna 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 you know if I'm saying if I think like, okay well padding for I don't like that. I wanted 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 three 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 colors here, but what it will do first is go look in your theme if that color is defined in your theme. It will take the theme color. If the color is not defined in your theme. It's gonna like take the default. So you of course could pass like a hex code here or something as well, but essentially um, it's giving us the it's giving us the power to just choose right? So I've also got the finding my theme colors background. So if I wanted to I could go over here and give background as well as color and it will just go find that in the theme and it should update it to whatever I defined. My theme is the back they go the background color. Cool. Hopefully that makes sense and 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 component libraries is like colors and spacing and layout stuff like that does 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, you know any sort of like finger designs whatever which don't speak the spacing scale that that's something that yeah, you need to pick up and have a joint responsibility for I think one of the things I like to do is actually try it. Well if it's if you happen to work with a designer who's kind of interested in coding like a little bit is half and take ownership really of this stuff completely like the file if it needs changing then that's cool can never discussion about it and change it so it's an array so from zero, right? So if I did the number four zero one two, three four, so I'm gonna get like 32 pix. Case yeah pretty straightforwards 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 need to pass that to start 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 I'm gonna do is quickly switch back to everyone. Okay better. Sorry my eyes the question. Yeah. Yeah, please. But could you show one more time that in file, please? Yes, absolutely. Very simple theme file again, but so does. All the style system understand that empty props are related to Space theme probe. Yeah, great question. the space ones in particular it's essentially the default. So if you have a look in the documentation of the theme specifications those Styles seem like so just how you need to name like correlate like margin part in with the theme exactly. Yeah, and this is something we'll talk about later. It's like when when you're thinking about building your own component Library, it's really good to take some inspiration from something like this and actually the chakra you I component Library they use this thing as personification like this is what there's is based on as well, right? So in response to your question definitively, yeah, it's expecting this stuff. Right? So he knows the colors it knows kind of how to go looking for it. And that's why when I go because background is coming from the color utility. It's going it's going to the theme and it's expecting to see a key called colors. And if it finds that it's gonna go 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 def. is right for so it's flexible like that as well and like I was saying before you could also give it, you know some sort of The hex 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. So to find them up here outside as well. So it's just a JavaScript object. So we have a lot of different options. That's also one of the things always worth discussing the penis like what how do you want to go about doing this you want to put them in line, but 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 but Going back to the example. Yeah, so like here I can just go for background. And I should. I'm not looking at it now. There you go. Just picks 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 like start adding those to your style components and then you just get all of this 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 can demo that one quickly as well, but it's as you would think. There are a bunch more you could add more like you could add as little or as many as you need often a fully featured component Library will 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 products based styling for everything because they added all of those in all of their default all of their components like you just have access to this stuff. Yeah another question. Yeah. Oh can we use relative units was for space. For example? Oh you can do that as well. Yeah, that's that's fine. You can just Define in your theme. If you you can Define all of those as like ends and I think actually over here and the same specification they talk about that. Yeah, they go. So you can just you can just use them. It's different to that question simply but later I'll show you in the chakra have a good example of how they do it as well. Like how how's their default theme done? You can also see that there there's a couple of nuances with this but essentially just use ends around if you'd rather do that. So we we just need to put in the theme in the in this place in our array of space and like using the units. Yeah, so yes just numbers but with units exactly these numbers are just gonna default to pixels, but you great so it gives you full flexibility that 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. Yeah your task here with this exercise. I'll just put it on here as well with the style system is yeah important space and color utils applied them to the style other component try sort of changing stuff try out the padding background teller color and don't forget to reference the API to see like which props you can pass Etc. 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 star 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 adding those in the bottom here. And that will 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 variants that we were talking about. So we go back here have a look at the variance example. So here I've got this and this is something that almost for sure will come out this little one as mentioning before it's the most kind of common thing that you have a variant and you want to switch that variance so my props, how can we do that? Pretty straightforward as we saw on 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 the components. Why because then you see how I'm passing nothing here. It's getting it's still getting the primary variant. Right? So it's the same as passing here very in primary. But what I'm going to do is pass secondary, so you can see that it's yeah, there we go. Get all so 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. Okay. 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 I put 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 to primary and secondary so you can come in and of course you can use, you know, the predefined space and 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 alert style add it and then have a go for well, let me show you over here as well. Basically create the variance for these you probably seen this type of thing before you're gonna have four variants here. So like default success error and warning have a grow creating the variance for all of them and you can do that over here in the theme. Giving you some colors. But once again, feel free to also bring in those steam 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. It's that if you look at the Box, they have a slightly different they're using Slightly different API for this but you can do it both ways, but I'll explain that a little bit more on the wrap up just not so confusing. Now, what I would do for now is full of the example try to get the variance working. But if you look in 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. That you can also have a look and you know try to implement the variance the other way as well. But like I said, we'll get into that in the end because it will make more sense. Just don't want to confuse now. Um, okay someone have a question. Yeah, I had a question. I've been a lot of these examples on previously but I was just curious. If you have any record questions 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. Um, let me have this. Yeah, I don't have a particular recommendation. I suppose this is the easy answer on this one. Um, yeah, I mean you can suddenly end up with like a lot of variance. I think this is one of the things where yeah, if you're gonna 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 deep are seeing think about this stuff. What I would do is look for some inspiration from like existing component libraries like you look at how short you I did it for example is kind of a good piece of inspiration. I haven't personally used any any additional things. So in order to like composing kind of compound them forever. So yeah, sorry, it's not a super satisfying answer. Yeah, like like at least like from what I've seen in my experience that going out from like right like simple like primary secondary. It's okay, but then when you add like 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 dish and I was wondering if there was like something extra, but okay, but thank you. Yeah, no worries. I guess the really key thing. I would say is like how I will talk about this in a solution as well a little bit. It's like how do you like I'm extract all the common start, 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. Yeah, it's true that it is a tricky problem. If you get like too many variants, I mean it 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 prop space styling as well. So if it's like one-offs, 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 you know, use the props space styling for the one-off changes. This is a bit of balance. I suppose to be had there. Yeah, hopefully that makes sense. cool Alright, so that's that one. Um, 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 employ you to yeah have a look at the API in 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 implementing the variance 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 organizing it. Cool any other questions? Okay, what I'll do then is create the breakout rooms. So we'll take like some yeah like 30. Yeah, let's do like 30 minutes for this one. I think it's probably reasonable. But yeah just ping me if you start finishing earlier. You have questions ping me and I'll be happy to come and answer them. I will come around and visit the breakout rooms. But yeah. Feel free to start and we'll meet back here in yeah 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. Um, yeah, just a bit of variance. Hopefully you can sort of see The power of variants like I say I always kind of keen to keep these things not to 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, it's what you would expect one thing. I would highlight in the with the style system one is that you know, we have this question and you probably saw this if you were looking at the dogs about like whether or not to do you can do in stock components these things in line you could also do this inside an object. We'll see that again in a second in the variance. I'll show you what I'm talking about. But yeah, hopefully you all got on okay 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. So there's obviously a lot more than just like space and color in this case. Cool, let's have a look at the variance because I've been able 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 to be do that I guess most simplistically yeah was what we were talking about you 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 gonna come in it's gonna find alerts here and then it's gonna look here for the different variants right 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 you know, do this sort of stuff in time script. You need to create an interface for that and give it like your different a lot 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. Another argument in can take an object and so here this is just pure like CSS. And yes, right. If you bear in mind though there that's not like CSS like we were doing before that you need to use the object syntax. I mean it is still gonna result in CSS, right, but you need to change everything to camelcase Etc. So that's just like an option so we could also let me just uncomment it so you can see Gonna have to comment this one. So one option that we have which probably went for based on the example is like this alert and then you put like 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 still working. If you do it in line, then I guess the advantage is essentially within line variants is you're defining the variance themself in the components. So like everything's in capsulated within the components so when you're trying to reason about that, Um, that's kind of easier to reason about hesperiance. Of course, there's a downside to it means that you can't like drive that stuff from a theme. So but style components is super style system rubber super flexible. So it does let you do both as you probably also I'm sorry the docs but you see if I come in 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 in line. 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 literals. So you can do it. You can do something like this. If you want to do a mixture of both you can do that. You can put all of your there's nothing to stop us doing this either right with the you have the back ticks put 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 Varian 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 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 this a sewer already. I mentioned Richard it's better to keep all the like styling like all the variables like in one place or in one theme piled. Yeah, it's like when it's located in different places you like lose control of anything or 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 driving from one particular place being the theme and that's why so you can clean these up like a lot right? 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 bass stars of component here and also write them insists. Like I can see utility of doing that. But yeah, honestly the way that I've often done it in the past. It's like I really like to drive it from one place because then you have a single source of truth right then you can start to do stuff like, okay. Well I have these common alert sounds fine, whatever. You know, I can do this right? It's just JavaScript. It's just objects and tax plunk it in there. Of course. When you're doing this, you're back into the the other problem that we have to look. Of course. This is camelcaser. I want this thing border radius is not bored of that radius. And what's the problem with that? You might think is 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 to code because they probably know CSS, right? 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. In fact in the documentation. What we were just talking about is kind of covered here. I know that this whole thing with two different apis is a bit, you know, but once you get to this stage, I think with components and feeling 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 Learning how to do a component Library. Yeah. I think you had a question as well. Yeah, I just wanted to say that there is like other side of the coin. So like all this variant. They are component specific. And unless we are like in the example of the theme file which you use we store like some colors in some like JavaScript variables. So if we are using this like JavaScript variables, I don't know which example what there was like some wearables that I used invariance and unless we we use the same colors like the same like spaces and so on so it's like simplifies when you store variance in components like the bargain of this component. So we it's very related to what and then we all looking how that varians are used like in the bottom. Yeah. Yeah, definitely. I mean, I agree more like it's like a Metro choice if like any anyone in the team likes like in one way and why not using them if it simplifies the development. Yeah, exactly. That's the thing. I mean, yeah, so we have to make the decision as as a team, right? Ultimately. It's like you want to do the variance in line fine, or you want to do them? I'm kind of like this. I think that ever just trade-offs and the main thing is to make a decision. It's like this disagreeing Command right where we can have a discussion about it. And then we just like pick a course everyone agrees everyone's aligns and that's it. And then that's something that we should probably have in our like 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 and then all of that feeds into code review, right? So when you start to see people like mixing that up, that's where you sort of say, oh in the pr of you like Hey, we're using this convention and I think that yeah, that's that's where the human element comes in but it's important. It's important to maintain whichever part you pick just stick to it. It's my recommendation because yeah, I think things become messy and coding when you get all of these different things as part of the problem with the job World in general all these different ways of things the same thing and then can cause US problems. Actually when stuff starts to scale right the more people. The more that that would be apparent. Cool, that's most of the things I wanted to cover from that. So yeah, I'm hopefully most of you I think maybe we'll just skip the break. Hopefully you manage 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 so we've seen we've already touched on some of these things but it's super important to try to create these generic. I just turn on the light this generic interfaces. Creating components in storybook would really help with this. I know we didn't talk about this in here. I'm sure you're probably you've all heard of it unfamiliar with it. You can also use a tool like chromatic to really quickly. I think some of the story that maintainers you say it would just give you like hosted story book like out of the box. That's all so really cool right because then With that you can it's a really good space to not only do the devwork and sort of collaborate with other developers. But also your non-technical stakeholders can go and see what you're up to your designer as 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 much easier to reason about that's something that you know after an hour or so, they're gonna get the hang of how to sort of like, um, you know do some coding over that at least a 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 compound library and the second thing that I want to talk about now is like bright and RFC. I will there's a template that I really like for building making RCS is this one here again? All of the links are in the GitHub repository at the bottom of the reading you've got like all of these different links of things. I've been mentioning. But yeah. Create an RC. 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 is 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 and just a moment as well. But what I would recommend in the RFC is establish a minimal approach to take within the project and then do this thing. We just mentioned right like have a discussion not too long disagreeing 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. Yeah. I think you had a question. Here result is RFC some kind of architecture design document. Yeah in diver quite quickly. So RC is a request for comments. Yeah, so essentially you might have heard of this concept before where there's like an open RFC. So, you know hooks in reacts started as an open RFC. It was like, you know things like that. It's like hey, what do you think of this should be, you know introduce this big change like in the library and you're just basically asking in the open source world when you do an open RC, 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 you're proposed changes are what are the limitations on 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 on goals background and motivation like, you know, what are the architecture diagram process diagram? So we do this the system design changes as well. Um timeline although sometimes I sort of get rid of that one. I'm not super fond of timelines. What dependencies are there? What alternatives are you considered? Um, 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 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 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 that? You should open that to challenge really what's driving the change like what is the pain point that it's really gonna is there a big enough pain to do this thing and to fix it? Is and 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 there's some of the questions and some of you asked during this presentation like the specification. How is that organized? Like, how are we gonna name our colors like in the keys like all of these things? I would put them in there and agree them up front because this this up front planning really helpful. Also, you know, the typescript module declaration the variant stuff. Like how are we gonna 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 for the proof of concept and then yeah some key components that you might go for first. What would the fullest 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 that we faced into it was like there was already a theme but like some developers were not using any of the values from it somewhere so they were components where they were just ad hoc spacing and then there was some coming from the theme there was some colors coming from the theme that there was also ad-hoc colors and it was like a mess but it's like well if there's already one how you're gonna deal with the Legacy one. There's actually a way by the way in typescript of When someone's trying to use a legacy one, it has like an app that procated and it will just like 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 were sort of stop right and refactor and just all the existing components. You just used a new theme and that's wonderful. Okay, but you probably don't have time to do that. That's why you need these type of strategies that I'm talking about where it's like everything you we're gonna like drive that from the theme we're going to use the new component Library. We're gonna build new components, maybe even as we go for the component library, but everything Legacy We're not gonna get around to refactoring that all in one go, but if we touch it, maybe we refactor later, right? So anyway this kind of thing. Yeah, and then pros and cons open questions to resolve and abandoned ideas. That's it. Those are the really key things that I think that an RFC should cover. I would highly recommend doing it definitely because there's just so many when you've seen doing this exercise it almost raises more questions right about all of this stuff and this is where we need to align with 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 has really key if it's going to be successful otherwise can be quite frictional. Any questions about any of that? Hopefully makes sense. But do we hear some example of this prefilled erosive document? Like a completed one. I'm sorry. Yeah, I mean to make inspiration from here. Yeah, let me see. I think yeah, I was actually thinking about adding on to slide the problem. Is that the one from the company? I was just working. I can't really share it like this kind of proprietary or whatever, but I can let me see if I can make a modified example and I'll ping it in the Disco channel. Oh, that's great. Yeah, I agree. It would be useful right for sure. It's just a shame. The last one I did. I'm not really allowed to share. That cool but yeah recommends giving it a go. Anyway, and you what I would say though is to have a look at the you can probably find some open rfcs, but just generally how to ride them like the ones in the open source Community but specifically for a component Library. Yeah. I'll see if I can do like modify it a bit and and ping it over on the Discord Channel. Okay, 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 our components. So this you saw that but in one of the first examples I think it was over here in style components. They have this isomorphic prop chords 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. It's going to be like a button even though this is like a style Dave that's kind of super useful right because essentially it just means that you can switch what has been rendered a runtime. So when components like links and buttons are all style 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 npm package you could do this, but you probably won't why I have probably because the ROI like the return on investments not super high until your company really needs to use the components across multiple projects at that point. It might be useful right to have it because otherwise you you're into this topic of like the mono repos, etc. Etc. It's kind of cool to just deploy it on npm and then you can use it across the whole thing. Great. That's what a company like Sainsbury's will do as well. So but yeah, you you might not get there to start with until it's kind of like really useful and you could you could also like hosted on GitHub. You don't have to use npm, right? You can do private npm ones. You can also host someone get help and I've done that before as well but companies that have Design Systems and 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 the your situation to be honest. Unless you're sort of like the solutions Architects that organization and it's a growth company. That's the one I can see where it's like, okay, maybe then it's your job to do it. But 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 Almighty component which can be used like in any places and there is no like like purpose for that component and there is there is like, oh, well, when do we need like do we need to use both component? What what is like the like the reasons to use it? It's like yeah temporary component for some like some component which was not like it doesn't with which doesn't exist in design component or designers. He don't like create a finished designs of people. What is your opinion on that? Yes a good question. So the way that I think about the Box Is almost like a primitive right in a component libraries the most primitive components like at this right when we want to do some like layout in web like where was using dips? So, um, 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 I think it was in this one. Yes. Same thing, right? So now it's like a powerful div. Why is that cool? Well, essentially you can get rid of this rapper, right? Because look at this rapper here is adding like 40 pics padding. Well, that's silly only that anymore right? Because why because quite simply if I want a padding us, you know, if I want padding I can add it here with this pee already adding padding. So in that way like the Box, you know under there's a dick there's something else here though as well, which is the like you can extend everything else from the box because if you say Well, the box has like all of these like base utilities that I'm going to use like for my From 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 could import the box if this is now button and you could do that and now you're gonna get all of those as well like you're gonna 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 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 as 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, um, 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 ride the RFC, this is 100% where you would start as well like, you know, when I said list the key components like the box is gonna be one of them for sure. It's like this is your sort of default component. This is how it can be used and you can just document the whole thing. Yeah, and maybe it has some you know, you can bring in there's these other star utilities like flexbox as well. So you can just do like all sorts of things of this. That's why it's kind of quite quite powerful when you can extend it. It's got this CSS prop. There's all sorts of things. So I think the styled style system utilities. This is when you're building a component Library, this is the kind of thing that Is super useful and that's why chakra uses it which we'll see in a second cool. So yeah regarding this as I was saying, yeah, you probably won't but you know Roll Up is just another module one. It's like web package set for packages. Right? So I've put a link in the GitHub repo again about it. There's a decent tutorial for how to do this. 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 day as I said, probably not massively high, but I'm it's worth learning how to do those things. Yeah package creation is always a fun thing. I've personally done it more for stuff like custom hooks both on npm and internally in companies. It's like where you've got some custom you want to share across different code bases a bit of reusable component logic, that's where I've found more utility. But hey, I mean eventually like a lot of stuff ends up in a 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. Yeah, so chakra Implement style system as you may have already seen it also implements a sensible default theme using style test system theme specification. I'll show you what I mean over here. So yeah, as you can see, they literally use the same themes specifications. We've just been using that's so should be really easy to reason about chakra now on like how to use it. So this is something you could get some inspiration from as well speaking of that RFC right? Like 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 can You know you can do like, you know Blue Dot 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 feature plan looks like so you've got like, you know, all of those different font sizes. They're using friends good for them. Because yeah, we should definitely wear be using like Romans and ends by the way, excess. 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 I mean if you go to the getting started you can see not the getting started over here. It's just a very good kind of sets of components that you can really easily customize get Nations into things. So as well who of course organized the conference that I'm doing this workshop for right now for most in fact impactful Community project. But yeah, I would say it's just it's 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 the whole exercise here like the You know, this project itself was put together with it. So like if you look in the at TSX file, you can see you know, my computer's having problems loading it. But yeah, you can see I build this like using track view I because it just means I can do stuff like this really fast, right? Like look at the margins my spacing a line and I can use all of these out of the Lost components very composable also has good accessibility has a good Community around it has a really good experience. There you go. Um, cool. So what do we want to do with chakra? Let's have a look so Important down the bottom Shack for 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 you know, some sort of Airbnb card or whatever as you can see, there's quite a lot of like prop space styling sometimes whenever I'm talking about this like internal in companies, I've had this reaction where it's like Ah, that's really nasty like 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 a theme and having like a decent set of default. You can override the default for any of these kind of exposes. All right, so it's easier like defaults for the text component. And 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 prompts-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 two in this case is not always two that's the case that you should use it for anything else. I would say, you know, if I see stuff like this is like wow. You know it's repetition. If you see it like more than twice or three times then think about where 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 chocolate sometimes will be like, ah, this is terrible but it's super easy to override. So you're oh 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. Okay. so Essentially your challenge with this one, which hopefully will be quite straightforward as well. But it's 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 just using that default theme that we just saw. But have a go at bringing in our brand colors and apply those to the design. So why not have a changing that background of the barge online 21, that should be this here. See it's got a gray background try to get that background to use one of those brand colors that we saw before like the mean green or something like that. Yeah, that's kind of the main thing and then as a bonus have a go, um overriding a chakra component with some custom Styles they talk about how to do this as well. That's what I was just talking about like this text component. For example, how would you ever write that like with some you know, your custom Styles and create new defaults. You'll have to have a quick look at the dogs the bonus. But yeah for the first part I think this is the really key part. You've got to chakra provider, but you haven't got the theme or anything yet. And then the theme TSX over here. You've got like not a lot. So yeah have a go have a look at the documentation. Try to get that going and yeah, I guess I'll give you like 15 minutes and then come back have a quick look at the answers. And yeah while you're at it have a play with this right because the cool thing about chakra is this implementing all the stuff? We just learned like all the style system things all those props are like already there, right? So have fun with that have a play around see what you can do. With this and yeah have a go Bringing In Those custom Styles and hopefully you will see how we could sort of 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. Right? I think they're using emotion rather than stock components for the CSS and JS library, but the API between that and start convert is the same so they're using essentially style components or similar and start 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 there in the main room. So I'll just I'll be here. I'll just probably turn off the camera and go me but please ask me any questions. I'm just gonna go and get some more water, but I'll be here in like from five minutes onwards. So just shout if you need any help with anything. Yeah, good luck with this final exercise. Cool. How's it going? Good. Thank you. Good you get a game? 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 there's a little bit of Looking at the dogs, but as you can see trackers are 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 prop space styling but also we can have that driven from a theme. So we talked already about chakras default theme. So of course all of this stuff relies on their default theme, so when it goes for like, you know the colors and things It's going to their their colors of which are quite kind of extensive. So if we let's go to the theme. That stink. I wasn't wasn't this one. It was this one. Well, anyway, never mind. Let me just show you the the solution quickly. So yeah, we need to do in order to extend it. So you're extending on top of the default theme that they implement. And the documentation which apparently I've lost a link to you now. Yeah, how do we do this with our Legacy Styles? So again, we pulled in these brand colors. These are the ones remember right at the beginning that we like exported them whether in those SAS files exploded Michelle's for variables and as well in our brand colors, and now I can use our brand colors right directly in Chakra. So it's pretty quick way to get going with some Legacy stuff. 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 in Psy colors. And then it's gonna take like all of these brand colors. So in particular case I've gone for this robin's egg. So that is why it has resulted in. Yeah that green color, but we could also do Let's try different one. So there's something called. Well, let's see. What we have in here. typescript ones to load What was the 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 it update over here in seconds. Okay? 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 bag badge component and inside my abstraction of it. I would do like import chakra by import badge as chakra badge from Chakra up here in a different file called badge and then I would have like probably, you know, if I want the background to be this default background color fine, and then I export it and I just use badge and that's like it's the that's where I would start with, you know these things because like I said before then you're sort of Planning for change right and you could even if you want, you know, you can also just give it the default props, but everything is is driven from from the theme so you can use variance here as well. Like you could pass a Varian you get to find that variant in like an extension of the standard theme, etc. Etc. Yeah, and then as an over idea you will have had to have gone to look to 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. Yeah. It's like basically fully fully customized. Oh, there's the theme. Yeah, 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're looking at before right the default theme so, you know you can find All of this stuff is just available to us out of the box in terms of coloring. It's a very reasonable default theme coloring font ways 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. Um, yeah, and it's already under the Hood's implementing all the things that we saw in this presentation. So 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 like between other stuff like, you know using Tailwind CSS, for example in States using other component libraries like the mui the material 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 gonna pick I can find a library of to use and it was someone else's we're 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. They still substractions like bringing in this stuff integrating Legacy and building small abstractions that are helping you like 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 gonna take those steps and approaches. Yeah, but hopefully that's helpful and hopefully you 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 so super fun tasks to do. Start with the RFC is what I would say and yeah any questions or comments about this one or anything else? I hear one question Richard. Do you know? So like India, like possibility stuff automate, for example, if we have few few more design automate creating all the components, maybe some clients in Lima. This is something that I would like. A cleaner to get what they didn't care. We just the chance to do it. Maybe you have some great advisors. Yeah. Yes. Again. That's a great question. I think there are some tools actually and I I suspect that Sigma are probably working on something with this themself at I tell you who I do know who's doing it is I'm the AWS and amplifier whatever it's called like that sweetest tools like helps you do this kind of thing like taking stuff from think and they're using AI to do basically right taking signs out of thing now and then like building a bunch of react to components essentially for you so that you're not starting from zero and then from there you can like fully customize fully modify those track components which were already like based. And 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 like do your whole thing, right? Like you're gonna have to do that at least for now right the feeling and things but I suspect quite soon. We'll see some cooling coming along Which does that where essentially youth grade A Design system in figma and then you like feed that and it's like creating an actual theme file for you and allowing you to then modify it from that and that would be really cool because we wouldn't have to right now the interface between figma and getting this stuff in the component libraries 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 is the best thing that we have but there's definitely stuff coming down the line on this coincidentally. I've been looking into all the things that people are doing with code generation recently and using like the the AI stuff like the GPT free models. And yeah, this is the kind of thing you can absolutely do and like the model would like 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 Taking over our jobs. I think I would still say. Oh, it's some way off that but it's definitely gonna supercharge the thing that you just asked right. It's like how do you get from like zero to one? quickly without with a bit less friction Yeah, hopefully that answers the question. Yeah, thank you original for the workshop and looking forward to repealed Ericsson quite simply. Yeah, yeah, I'll send it if you pay me a personal message on. Just ping me like a hello or something on on Discord and yeah happy. Yeah, I think something but yeah and the same goes for everyone else. Yeah, feel free to stay in touch on this chord. You can also yeah, I mean you can find me on LinkedIn. I'm not on Twitter so much especially now since this person take over and obviously I'm getting Hub anywhere else. Just reach out. I'll be around. Cool. All right. Well, thanks everyone for listening. Thanks for the participation. Hopefully it was useful. I hope you'll learn something and there was some full provoking stuff things to take away. And yeah, hopefully we'll see each other again one of the other good Nation conferences or indeed one of the workshops. Yeah. Thanks for listening and have a good evening.