So, yeah, let's talk a little bit quickly about CSS in JSC. So, we are doing a lot of work from the author to make it usable by the updates to the JavaScript library that came with ES6, essentially. So, hopefully, you're all aware of these kind of libraries, the CSS and JS libraries such as style components and emotion. You probably already know the benefits, but we'll just talk about it, very, very briefly, to recap.
So, essentially, it gives us full hand-held access to all of these libraries, which is amazing. And it gives us a feature of ES6. That's how it works. I've linked in the documentation, if you go to the GitHub repository, at the bottom, you have links. I've linked the blog post about how this works. There's another thing about how to use template literals in there. There's a lot of content there. I can't quite remember what template literals we had, but it was super new then and I still like it. But, yes, it's this idea that essentially you kind of can do style.button, it's like calling a function with those back ticks. We will see it in the code in a second.
Yes, I guess one small note about all of this, you can also, you know, if you really love CSS in general, partly because of all the updates going on in CSS as well, that is something I've missed is that both Python and CSS are quite strict on style. But if you're really passionate about going back to using CSS, it's always an option. There are no definitive answers to what's better, we can always assess, but for the purposes of this presentation, we are going to use style components as a library, so therefore, we are writing JavaScript, essentially. We are writing CSS, but ultimately what's happening every time is you're still there, anything you're calling style, you can always tell them, you're calling it. You can create a style component, which is your product.
So, then we're going to talk a little bit about what happens when you have a legacy codebase with a bunch of styling. You may have worked in places with things such as this, you may have some non-React components, so what I mean by that is just standard JSX components, and you have a bunch of different styles you might want to keep in that. So, what you can do like this is pretty straightforward. Hopefully, everybody on the course is familiar with this. You see the chapter wrapper component, you would just be like, okay, that's now style.div, use the backticks and the tag template literal is going to do the styling in there. You can do that, that's pretty straightforward. You might be thinking, what if I want to keep some legacy styles? You can declare my style components, like the attributes, and you can just use that. It's the first and only argument of an object merged into the rest of the components prompt. It does quite a bit more than this. I do recommend having a look at the documentation, which is linked here, but one thing I would say with this as well if you're going to do this, it's a little bit messy. You need to bear the specificity in mind. So, anything that's going on, and I'll show you in a second in the code as well, but anything that's going on in your legacy styles, it's going to be overwritten by the style components, like the specificity goes component first, so everything written here, for example, if I've got that border-bottom here, anything that's in that class name, it's going to be overwritten by that. So, just bear that in mind. Normally, you want to try to avoid as much as possible competing styles, because that's where we get into this mess where everyone starts to put the important explanation, and we want to try to avoid that, so avoid as much as possible, but, you know, you can face in to circumstances where you just need to do that, and you want to have some flexibility, so, yes, you can do things like this.
Cool. Just before I show you the code, I just wanted to give a quick aside as well about abstract components. And just making a small abstraction upfront. So, I would highly recommend this. It is just something from my experience and I've done this a few times now in a few different places. Companies of different sizes. It is often overlooked, but it can cause you issues down the line. If you're using a pre-existing component library, I would highly recommend that in your projects, in order to plan for change, you just make a small abstraction which can be as simple as make a new file, import the button as like whatever the component library button is from the MIUI button and simply export it again. Why would you do this? If you need to make changes, which you probably will down the line, you do it all in one place. Quite quickly code bases, if you start importing things directly from the component library, that can be fine to start with, but then you will find over time often it is like people make slight adjustments to these things in a ton of different places. Or you can make multiple different files, and that can be really hard to unpick later. It is just planning for change. In some ways, you might be thinking, it is a premature abstraction, but it is costing you making a file, to be honest, at the start and it will just help you and give you flexibility down the line. So, yeah, and also the thing is if you later want to switch or swap out the component library, you would just come here. And now, if you are using, I don't know, the chakra button, I mean, it is half a minute, and that is fine. You can use more than one, I wouldn't recommend that later, but use the one and it will take affect across your entire application, because it would be broadcast. It is something to consider. I would note here, if you are starting from scratch, this is the same thing you would do anyway in terms of your code structure. You would have components, you would define your own button. Components, you can say, for example, typos, and so on, but it is a good example of how these things in style components get extended, so you can parse a component and it gets past as a function. Then, you can over-write styles on top of that in a normal way. Cool. Hopefully, that will make sense. And, yes, another really good trick that you don't have to worry about is SangPress. You can use the SangPress as Sass variables, JavaScript variables, and you can use them directly. This is overlooked. Often people run into this situation where they're like, well, I want to use style components in the legacy code base that I want, but I need to use the Sass variables, that is needed. I've got an example in the code which I will show in a second of this, I just don't think that you have to go on a little bit of a hunt, but ultimately, as we saw in design system, there's going to be in a big company some Sass variables which are used for styling, and that's going to be stuff like the brand colours, and you can probably find those, and that's really, really good, because then you're always pointing at the original source of truth. So you don't want to just, it's easy to find out what, like, the hex codes are, whatever, but you want to keep pointing at the same place in case somebody comes along at a high level tomorrow different, and then, like, taking the randomness, you know, it clashes with another colour, or perhaps an accessibility consideration, for example. Any of those reasons. And then, suddenly, you know, your project is, like, off, and you might not realise for quite a while, and the whole point of these design systems is like bringing, sort of uniformity across all of the different products, so, yes. Also, yes, you can fully adopt CSS and JS in a new project, so yes, these are all good. So, I don't think we have any questions about anything I just said before we have a quick look at this coding stuff. I'm going to do a quick demo for this one, and then I'm going to stop talking, and we're going to do an exercise! So I was aiming to show you this code in less than30, 40 minutes before letting you do decoding. So, I just wanted to show you this. Cool. Let me just share, I need to share my whole screen.
Comments