Use Tailwind's responsive prefixes to apply specific classes only at certain breakpoints. Learn about two approaches for adjusting your UI for different screen sizes – sprinkling responsive prefixes on existing templates, or creating new chunks of markup to use at specific screen widths.
The code for this lesson is divided into two sections, with this you can see the progress on the code.
Lecturer: [0:00] The last main piece of our clone I want to cover is responsive design. We've been working off of the desktop view and when we shrink this, we do have some nice layout behavior here. Obviously, this won't work when we're on an iPhone.
[0:15] We can see already that we have some issues here. Right here, I have a screenshot of the Discord app on the phone. We can see mainly we're just hiding the server now from the left, as well as the channel nav. These actually come out in a collapsible menu right here.
[0:32] We also simplify the header a little bit. Let's work on adding this to our clone. First, we want to hide this server nav and this lives in our root app page. If we scroll down, we'll see this div contains everything in there. Basically, we want to hide all this on mobile.
[0:51] Tailwind has a hidden utility which we can see sets display-none. If we add that, that will hide, but of course, we don't want to hide it on desktop.
[1:02] We want it to start out hidden and then show it once we get to a certain breakpoint. The way we do this in Tailwind is with responsive prefixes. There's one called MD, which stands for medium. We can see right there that it applies to a minimum width of 768.
[1:19] At 768, if we set the display back to block, which is the default for a div, now we can see this showing up at 768 pixels. If we were to shrink this a little bit, it will hide. That's basically the idea behind working with responsive design in Tailwind. You use all exactly the same utilities.
[1:39] You just prefix ones you want to apply at certain breakpoints. Tailwind has a few different breakpoints by default. We have small at 640, medium at 768, large at 1024, extra-large at 1280, and then 2XL at 1536.
[1:59] Of course, all these can be customized, but just for now we're going to stick with medium for the 768 breakpoint, and that's basically the idea. Let's also do the same thing to our channel list here. This is over in our CID page. I believe it's this div right here.
[2:17] Here's our channel list, and here's our main channel area. We want this to be defaulted to hidden. We'll see right there we have a nice error message telling us hidden applies the same CSS property as flex.
[2:30] Since we're making this flex, we only want this to show up again on the medium breakpoint. Now that's hidden below 768, and once we get to 768, it should appear alongside our server nav.
[2:45] The way we've constructed this layout, we really don't have to change anything. Flexbox has taken care of making sure these sizes all work for us as we add and remove elements.
[2:54] Another small point is that these are mobile-first breakpoints, which means they are minimum width, which is generally best practice in responsive design.
[3:04] Even though we've been building this as a desktop because I wanted to focus on all the details that we've been focusing on, usually, when I build a responsive site, I would start by implementing the mobile version first. Then, as you get to bigger breakpoints, layering on these utilities prefixed with the responsive breakpoints.
[3:23] Let's shrink this down a little bit, check out our screenshot again. Here, we can see the header's really simplified to just the channel title. We have the hashtag-with-message icon, and then the team's icon over here.
[3:37] If we open up our main area div here and find the header, this is what we've been working with. Here's the channel description, and here's the label. We can do the same thing for the description. Let's start with it hidden on mobile, and then put it back to block for tablets. Now that hides, and again, it shows up once we get bigger.
[4:06] Let's take a look at these elements. These are all inside this div right here. Presumably, if this was a production app, there'd be a lot more functionality with all of these buttons and running this search, that were suitable to desktop.
[4:20] We could come here and apply the same technique, and start hiding the things that we don't need. Maybe this bell goes away, so it's hidden, medium, inline, something like that. As you can see, sometimes it gets a little confusing.
[4:38] If the differences between a particular part of your template in mobile and desktop are large, if there's a lot of differences, sprinkling a lot of these responsive classes everywhere can make it a little bit hard to follow what's going on.
[4:52] While that technique worked great for our layout, in this case, I would take a slightly different approach. I would just drop a comment right here, that says, Desktop Buttons. Then. let's just create a new one called Mobile Buttons. Let's grab this, paste it right here.
[5:14] If we take a look at the screenshot, we'll see we really only need the hashtag-with-speech-bubble icon for threads, and then we need the people. We can delete all the rest of this like that, save that. If we come back, we're doubling up.
[5:33] We want to make this one visible on mobile, which it is by default, and then hide it at 768. We'll say, medium hidden. That will apply the display-none class at 768 pixels. Then we want to come down to our desktop and do the opposite.
[5:51] We'll say, hidden and then we'll make this medium flex. Now we have a much simpler header here to work with, with these buttons. We don't need to go looking for where our responsive utilities are.
[6:06] It's just easy to see when we're working on mobile, which has a pretty drastically different treatment than desktop. This is what we need to look at. Otherwise, once we get up to 768, we'll just switch back over to this one and this will hide just fine.
[6:20] That's my two ways of thinking about working with responsive utilities in Tailwind. They're super easy to just sprinkle in if you have small changes to make between breakpoints. When you have larger ones, you can just separate them out.
[6:33] There's no always right or wrong answer here. You'll just get better with experience and knowing when to use which strategy. With that, we have a pretty nice clone here. Of course, building all the mobile navigation is pretty involved, and beyond the scope of this course.
[6:51] You can see that our flexbox layout, our fixed header is working really nice. The scroll's working nice. When we go up to laptop size, we see all of our original elements and everything is looking really great.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!