For this, I mean, there's a long list of CSS and JavaScript, right?
I can't even begin to cover it all, there's just so many.
But I would say some of the some of the most popular ones are probably style
components, emotion, if you've ever heard of those.
So I wrote an example of how to do style components.
With that, and
I'm not gonna write this down because we're not gonna use style components.
But I think it's interesting just to show you all the work you need to do to get
style components to work.
So basically, to do CSS and JavaScript,
because of the nature of how everything is rendered on the server in Next.js.
You have to do somewhat of a setup to ensure that actually works through
the server and then through the client.
So there's a lot of things you need to do.
And this just kind of demonstrates all those things that you need to do,
it's kinda tedious just to set up some JavaScript or
some CSS functionality on the client side, and have it work on the server side.
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.
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.
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.
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.
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.
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.
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.
So- >> [LAUGH]
>> [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.
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.
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.
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.
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.
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.
>> Yeah. >> 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.
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..
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.
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.
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.
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.
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.
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.
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.