Transcript from the "CSS in JS" Lesson
[00:01:00] So I actually tend to avoid this but I have this here as a reference if you wanna use it it involves a lot of stuff. But basically rendering a stylesheet on a server and making sure that it's appropriate, and it works as it's being downloaded, and different things like that.
[00:01:15] Inserting that stylesheet manually yourself through a hook is something that you have to do But maybe you might have to do this one day, so there you go. There's something called a StyleSheetManager that you get from StyledComponents, and this use server inserted HTML, which is exactly what it sounds like.
[00:01:38] I should take HTML from a server and inject it somewhere. So in this case, a StyleSheet. So it's kinda tedious, but that's what you have to do. Any questions on styling? There's also more that I'm not gonna cover, because I don't think you'll ever use them, but I guess it's worth listing.
[00:01:55] So you have style.jsx, which is something that the Next.js team, I think, made, actually, or at least for sale. And it basically has a pretty similar setup, because it's CSS and JS. And then did they not have an example of it? They have an example of it. But basically it's like you can do, I wish I showed an example of it.
[00:02:17] You can do, let me show you. You can like write the JSX, like as a component in a string almost, it's kinda weird. So it looks like, its like this, right? Yeah, like a style tag, where you can write JSX. And inside of that you can do the CSS.
[00:02:33] So I don't know that feels funky to me. Probably you won't do that. But you could do it if you want to, it works, I guess. I don't think you'll see a lot of this in the world. Also, I think this was created at a different time where people did different things, it seems like this hasn't been updated in a while either.
[00:02:51] At least out of the source code, source code is updated eight months ago. So you got that, you also have, what's another one? I've never heard of Tamagui, but seems cool. But then yeah, here's emotion, here's material, here's chakra, chakra's a big one. It links me to an issue, so I already know there's a problem, I'm not gonna look at it.
>> [LAUGH] It linked me to an issues. So we just we're not even gonna go look. So this is why I just stay away from CSS and JS in general. What Next.js is just like, unless you got a really good reason to do it, I highly recommend not doing CSS and JS.
[00:03:27] Just either use style sheets or write the CSS yourself with tags or something like that. I personally like to use something like, I can't even think of the name of it right now, cuz I haven't used it in a while. But because I've been using Tailwind. Tailwind is probably my favorite, but there's another one.
[00:03:45] Let me see if I can think of the name of it. I know ThemeUI uses it. So ThemeUI uses, they basically hijack the, See they have an example of it. They hijack the JSX parser and allow you to, there you go, they allow you to basically hijack. They allow you to tell the parser inside, like the bundler that's bundling your JSX, whether it's babble or something like that, to say, hey, use this JSX compiler instead.
[00:04:17] And this JSX compiler adds a prop to every single component called SX, which is basically like a style prop, but a little more dynamic, and then you can style it that way. That's probably my preferred way to style components. So typically, I only work with component libraries that have this built into it, that you can just dial it this way.
[00:04:36] And then that way, I can change whatever modifications that they might have had. So this is typically what I look for. I see this as a standard now, it's like you see in the SX property. And you can see right here, this is them overriding the compiler, doing something like this.
[00:04:50] So pretty cool, I like it, that's probably my preferred way. If I'm not using something like tailwind, which is probably what I'm using, okay? Cool, any questions on that? Yes?
>> This isn't CSS specific but it kinda gets to file structures and different names.
>> How do you incorporate, like, testing files into this file structure?
>> Yeah, I think when thinking about testing files, it comes to two things. One, the same as before, it comes down to what convention you wanna adopt, underscore not putting a page or just bringing it out. You can do that, you can also just put a test in every single one of these directories and and that will work.
[00:05:34] So that's one thing to consider is it's like kind of whatever you see fit. The other thing is considers what tool you're using and how it looks for testing files. So some tools prefer you to have like a testing folder where it looks for things, some tools like you just give us paths and will give us a glob we will go find all those files for you..
[00:05:52] So I think it depends on the tool. I think most tools, probably like Jest or Vitest, I think that's the one I've seen people using lately. They don't really care where you put it, because you can give it a glob, right? You can tell it where to test and how to test things.
[00:06:16] So I don't think there's a right way. Me personally, I just create a test folder and put all my tests in there. I used to like co-locating all my tests into like the actual thing that I'm testing. I used to write all my code that way but now I don't like, I think I prefer to see things separated by functionality, then by like topic.
[00:06:35] It's like this is everything about the blog, so for the blog css here, over the blog page, the blog test, the blog storied book, for all that here. I'm kinda in the other boat now where I'm just like, no, all style here, all pages here, all tests here, all story books here.
[00:06:55] I'd rather see it that way because I feel like it just gets, I feel like you're almost, it's rare in my opinion that you're looking for everything about one topic where in reality, I think at least the way that I build stuff, I'm just like, I'm making all the pages right now.
[00:07:12] I'm writing all the tests right now, I'm not going writing all the tests for this one thing. So having to like switch between all these directories to find all the test files is like annoying to me, right? To see them all at one directory. So this is how my brain works.
[00:07:23] But I can see like on a team, where it's like broken outs like this team works on this, this team works on that, this team works on that. It's probably better to separate them into their own folders of like topics here's this one folder, there's one team works on it, everything they need is in there.
[00:07:36] And there's other folders this whole team works on and everything they need is in there versus it being spread across folders of different functionality. So I don't think there's a right or wrong way, but it just comes out to preferences. I've just been doing this for so long that this is just how I like to do it to save me time, so.