Components We Need on Every Project

Welcome to Syntax. Today, we have a show for you on components and utilities that we need for every project out there. So whenever you're starting up a new project, I I find myself making a lib folder and either copy pasting, npm is stolen, making my own. And then the same goes for, like, UI as well. It's like, oh, I I feel like I need these things in every single project that I work on, which, a, JS awesome that the browser is actually moving towards giving us those, but we're not there yet. So we're gonna talk about all the different components out there, whether you should build it yourself or install something and a whole bunch of stuff around that.

My name JS Wes. I'm from Canada. With me JS always is Scott. How you doing, Scott? Hey.

Doing good.

Doing super good. In fact, I've been working really hard on a starter kit for myself, Wes. When, we went to React Miami, I showed you a. The dance app that I built, and I I I built it really rapidly. Like, I built it on the plane right now. Impressed. Like, very impressed at how quickly you put that together.

Yeah. So I figured, hey. You know what? I have this kind of starter that I I work with typically. Like, what if I were to just really formalize that? So I I've been working on a a starter kit that kind of encompasses this stuff, and and it really has gotten me thinking, like, what are things that made that development process fast? What are the things that I needed in that site build, but I end up needing in most builds over time? Because when you start any project, you can often feel like, hey.

I only need this and this and this, and then, oh, wait. Never mind. I need this as well. I need a Toast menu. I need this. I need that. Yeah. And next thing you know, you're rebuilding or adding, like, the same components to every project. So, yeah, I thought it would be a great topic to go through some of this stuff. It's been on my mind. And what else has been on my mind is the errors that come into our century because let tell you, they come into my email, and I see them come in all the time. And and some of them are ones that we need to take care of rapidly, and others are are ones that we can maybe just wait and see a little bit. But it's important to me to have a handle on the errors on the syntax site, and we do that via Sentry.

And Sentry presents this show, so, you know, we have a close familiarity with the project. But with Sentry, we get access to being able to track all of our error logs, being able to track performance on every single page, track performance queries. And now we're able even to track analytics and metrics type things via the metrics platform where we can track who's listening to what episodes, how many episodes are being listened to, and which ones, and when, and how how much, and stuff like that. So if you need these types of tools in your life, which I'm gonna guess you do if you're shipping software, head on over to century.ioforward/syntax and sign up and get 2 months for free, especially if you're building any projects that need components like what we're gonna be talking about. So I think the first one that you know, when I when I think visually about this, I would start at the very top of the page.

And one conversation I think that you need to have when starting any project is about the nav and the mobile NAV.

I wanna know, like, Wes, when you do a NAV, are you thinking what what's your strategy for having a NAV? Is this a nav component that you copy and paste from somewhere? Are you doing the hamburger menu thing that you you bring from thing to thing, or is this something you end up rolling your own each time?

Yeah. I I almost always roll up myself because they're really not all that complex. Obviously, some navs can can be relatively complex, but I always try to just start with very good and descriptive HTML that can be moved around and shown and and hidden with CSS and and styled. So I really don't stumble upon too many use cases where I do need it. But I don't know. I've I've had a couple of projects here and there, and the ESLint side is is one of them Wes it's fine to do 2 separate navs. You said there make sure that you're when you are updating them, that you're updating both of them.

Yeah. And that that is, like, the tough thing because I don't know how many times I've been able to reuse the desktop nav into the mobile nav 100% without hiding things. Sometimes you can just get away with CSS display none on some things you wanna have available only on mobile and some of them only on desktop. And sometimes, like, the layout in the the HTML structure is completely different. So for me, when I'm looking at do I have a mobile nav component specifically and a desktop nav specifically? It's almost always how much is the structure different of the HTML.

If the HTML is the same, we're doing 1 component on that bad boy and having it all work with just CSS.

If the structure is different, which it happens a shocking amount of time where the structure really needs to be different.

Like, could could you give us an example of, like, where you would need a totally different HTML structure for Node for another? I I tend to just go overboard with the classes and extra elements, and then they're there if I need them. Yeah. I think that ends up becoming a big thing. I think also one thing that gets people is if if you have to reorder items in the mobile nav, it can be kind of tricky to do that. But now we have, like, CSS grid.

It's not ideal to have to, like, reorder them in CSS. Sometimes people prefer just to reorder them in the HTML because it shows up as you see it, but you could do that with with CSS as well. Yeah. I think the thing that I think about is sometimes there's items

within the mobile navigation that either don't exist in the desktop navigation or the way in which you want to have them really appear. I guess the thing I want to say specifically is that you should always try to have them be 1 NAV first and then maybe as a last ditch effort, then you can make a second one. Because like Wes said, you if you forget to update 1, you forget to update the other one, that can be a big issue. And in fact, I think the syntax website, Wes, being 2 different components Yeah. Might have been left over from an older build of the site when we needed it for some reason. Because now I'm looking at it. There's absolutely no reason why we couldn't have these be 1 component on the current version of the site. So that might have been something that was modified over the course of time. I think I think we initially had

either a search or we had, like oh, no. We had, like, a multilayer nav that was a little bit different in on mobile because that's the other thing is you can make a very complex nav on desktop, but if you go on mobile, sometimes you'd need to pair it down.

So, yeah, we we should switch that, though, now that I I'm seeing it. Yeah. Same. That that is funny because I'm looking at this for an example for why we did that, and it I'm not seeing any particular reason. And I'm usually very focused on that when I'm making it in the 1st place, so I definitely had a reason. But, typically, it's it's not a huge deal to have a mobile only navigation if you don't need it or if you need it.

Can I tell you one of my beefs with websites is they start their mobile labs way too early? Oh, yeah.

They're like, oh, 10/24.

Let me pop a burger on there so I can clip it, and you can click it. I hate that because, like, I I often wanna put multiple windows open at once and a 1,000 pixels wide is I'm not on an iPad. I'm on a desktop, and I don't need to do it. Just make the make the text smaller or wrap them or something like that. So I think people are a little too aggressive with the hamburger menu to a navigation. I much prefer just give me a stack of links at the top if you can fit them in rather than having to hide them behind some tiny little three lines. You have to click it and open it up. I'm gonna tell you why. A pain. Why? They're lazy.

Because it's the easiest thing in the world to just say, oh, they're getting squished. Let me just throw them behind a hamburger menu instead of having to worry about maybe, clamping the text or not doing what the text says. Like,

a lot of people are using Tailwind, and Tailwind comes in with the predefined breakpoints.

And they just a lot of people just use those breakpoints, which is good for, like, thinking in terms of, like, small, medium, large layouts, but you should also be thinking, at what point does this menu become too odd for this use case, then that's when you should throw yourself in a breakpoint.

Yeah. I almost always keep the the desktop nav available until the last possible second, and I think that should be because you don't wanna get have to give your users 2 clicks even on mobile if you don't have to. Another one here is the header, which I often do a header component, which is usually just, like, very simple. Right? You either have your logo, and then you split it, and you have the navigation. Sometimes you have search up there. Sometimes you have, like, a user menu where you can do logout and stuff. But a header component is really just a header HTML element with some CSS to kind of put things in the right place. But I think the big question here for me that I have for you, do you prefer a fixed header or a non fixed header?

Almost always a non fixed unless it's giving me some information. Like, I'm looking on on GitHub right Node, and as I'm scrolling through some code on GitHub, there is a fixed header of information about what file I'm in, what branch I'm in, how many lines of code. That's helpful context that I want to see as I'm scrolling.

But if you're just fixing it because it looks cool and like like I don't necessarily if I want to go to your navigation,

I'll scroll back to the top and and get that. Yeah. It's a lot of space too. A lot of people's headers are what? Like, 60 some pixels tall, taking up a whole lot of space, especially on mobile. Remember, there was that whole headroom trend for a while. If people don't remember this, there was a a trend that Wes on every website in the entire world. When you scrolled down, the header scrolled away. And then when you scrolled up, the header gone whoop and, like, came back down. Oh, yeah. It bugged the life out of me in practice. I actually didn't mind that because Mhmm. Well, maybe I did.

It depends. You know? Twitter had it for a while. It was novel at first. I did Yeah. I did like it for the nav bar because you could Scott, and you could have nice and clear. And then if you wanted to pull it up, you can do it. But it's it's it's very subtle because if it happens by accident too often, then

forget about it. Yeah. I think that's how Safari works in general. Right? You scroll like, mobile Safari, you scroll the the URL bar goes away and stuff. But now if the website's doing that too, it's a little much.

Yeah. Node one component I find myself needing on literally every website that you might not think about JS being a standard must have component, but a Toast message.

Alerts are a little too invasive. Oftentimes, you need to let the user know that something happened either good or bad. A Toast message is something that I I don't know if I've made a site in the past little while without a Toast system in general.

What about US?

Yeah. I usually will reach for in the last call project, I've I've reached for the Shad c n one. So we talked about this in the last show. It was, like, you can build it yourself. However, there are a lot of features in the, like, more featureful ones where you can update a Toast message. You can have them auto dismiss. You can have touch events for swiping them away because, like, a lot of people are used to Ios now, and Ios lets you swipe them away. Mhmm. And sometimes you see like, sometimes I'll see somebody, like, on a an app where they have their own built in notifications, and you can watch them try to swipe it away, and it goes, oh, it's not it's not actually built in to to work like that.

So I I would reach for an external component for that type of thing.

But I feel like this is just the you know what grinds my gears episode. So maybe for each of these topics, you can just ask me what grinds my gears. I like that. I have a very large Sanity.

And more than once in the last month, I have done something on an application, and I thought it's not doing anything. Mhmm. And it's not doing it. I'm like, what is going on? And I realized, like, oh, let me just, like like, move over on my rollie chair to the bottom of my monitor, and there's the toast message. And the toast message was so far disconnected from the actual UI because they're probably not thinking somebody has a 32 inch 4 k display, but I think if that's the case, you need to maybe think, Could you play, like, a little sound with that? I got, like, a little click. I know people don't like sound, but little boop boop boop to to show you that something has happened. Because I've I've, myself, have noticed it. And I think, like, man, if if me if I had missed that, how many users are accidentally missing that?

Yeah. I don't know about how I feel about it sound because, like, Discord bugs the life out of me with how many sounds it makes all the time. And I I told it everywhere in the possible world, stop making sounds, and Discord still makes a sound somehow occasionally.

So sounds can just can bug me a little bit, especially with something that like a Toast, but I I could see why that would be nice, especially if the site makes it easy to turn them off. Or maybe just, like, put them from the top or Dude. Put them closer. I I don't know what the answer is here. Let me tell you, Wes. I think the best place for a toast message is either dead in the center, popping down like, boop, like a little Node or the same thing at the bottom, dead in the center, beep, coming up from the bottom. Or a tray

from like, you have, like, a little notifications item.

Mhmm. I have a tray. Different. It's like that's app wide notifications.

You know? Totally. But, yeah, for those of you who don't know, a Toast JS called a Toast because it just pops up. It's a little pop up, and it's a an alert or a menu, something like that. The one I typically reach for myself with Svelte is Svelte French Toast, which is based on a React library. But the thing about that is is, like, libraries like that, like you've mentioned, they do have a lot of which is great. But sometimes they have, like, an absurd amount of too many options. Like, oh, each time you you send a toast message, you can send it to a different spot of the screen. Like, how many times do you want that? Or Yeah.

You know, like, typically, for me with Toast messages, they they do couple things. They pop in, the, like, the main setting you need to change is the position and the duration, maybe the offset, how far away from it is at the top left to bottom, whatever. And then, like you said, the built in stuff like the swipeable is is, like, really what matters or making sure that they pause when you hover over them.

I built my home recently. It's, like, really dead simple, and it's, like, super bare bones. I think the only thing I will add to it is gesture support, but I used inset.

And, Wes, let me tell you, man. I've been using the inset property along with logical properties to do positioning for this type of thing.

So I can say something like inset ESLint and or inset inline start or inset inline end, because those are actually properties as well using the logical properties. So if you set inset ESLint end to 0, it moves it all the way to the right. If you set inset inline start to 0, it moves it all the way to the left. If you set inset inline to 0 on both accounts,

it puts it in the center or auto. It puts it in the center. Auto. 0 would stretch it. Right? 0 would stretch it. Correct. Yeah. That's the pnpm. 0 would stretch div right across the thing. Yep. Inlines stretches it left to right, or, obviously, you can flip it if you change it. On what you want there. But that also works with,

inset block as Wes. Inset block start, inset block end. Yeah. Really, really, really nice and easy. I I like the fact that you can set the left and right or just the left or just the right with very similar properties, man, I I I end up using that stuff all the time. So a couple of superpowers there from inset as well as the logical properties together.

I'll I'll ask because people are probably scratching their head right now. What is the benefit of using that pnpm ESLint line left start all that instead of just top right bottom left? Yeah. Wes, because the the big one is that it's

easy to have that be a nonstandard.

If your users are not top to bottom, left to right, then this just works without any sort of adjustment or thought or anything whatsoever.

And inset itself becomes a a really nice property because you can set things like auto and have it positioned fixed in the center of your screen. I don't know if you ever tried to position fixed anything in the center of your screen, but it requires some goofiness.

You need to do translate negative 50% and then left 50% to get something to center correctly in the screen. So if you use this, you Scott only get pinned to the left, pinned to the right, but you also get pinned to the center without any sort of extra effort.

Oh, interesting. So inset auto will automatically center a fixed element, whereas top right bottom left auto does not do that, I think.

I did do a this is all while we're talking about these writing modes, I did do a little TikTok video about an actual use case for using inline and block CSS logical properties. So instead of saying, like, margin left, you say margin ESLint start. Mhmm. And the use case for that is if you were to ever flip your your elements. They change the writing mode so that they go they go sideways. So I showed an example of we have headers across on desktop, but then on mobile, we flip the headers to go to the left or or the opposite, something like that. So so, basically, you have the we'll get Randy to overlay it on top right now. And it was really cool because, like, that for me, I probably will never make a Japanese website in my life. And in fact, I even went to a bunch of Japanese websites, and the Japanese websites don't read top to bottom. You know? Like, I I couldn't find an example of a website that reads top to bottom. I found lots of examples of websites that read, right to left. Mhmm. Right? Like, that's a pretty common Scott of languages read that way, but I was I was having a hard time finding something like that. But I did find oh, yeah. Sometimes I just wanna turn text, and don't use rotate for that because then once you rotate it, it's out of the document flow, and then you can't use margin or you can't use anything like that. But if you just change the writing mode to I think it's Vercel right left, then you can you can write the text from top to bottom. And then your ESLint margin, your borders, and your paddings all will switch

the axes that they're appending to. Yeah. That's sick. Alright. Next 1 is a portal, which portals will become less necessary, but a portal basically takes your element that you're wrapping in and moves it out of its current position of the DOM and usually puts it, like, as a child of the Bos, therefore, pulling it out of the position relative document flow. And so, like, it's gonna sit on top of things. You don't have to worry about z index. But portals nowadays are going to become less and less important because we have the new popover API. In the new popover API, what it does is when you make a popover, it puts something on what's called the top layer, which sits above everything else.

And, coincidentally, that actually also means that you can no longer position something relative to its parent if it's absolute, which is why we have the anchor API. So they had to create a couple new APIs here. Either way, portals will be kind of going away the more and more that we get to use pop over because it is going to pull it out of the the document there. I don't think those are the only use cases for portals, but I think that's, like, the majority of them Yeah. Where people wanna just really pull it out. Like, in in React, we have portals because, like, most k most often is you're in a component that's nested very deeply,

and you wanna be able to render something out.

Like, for example, you wanna put something in a modal dialogue.

Right? You'll often use a portal for that because you need you need to put the modal, like, over top of everything, and that div is somewhere else in your application.

But, yeah, with with popover and dialogue and dialogue has a modal setting, we should do another episode on popover modal now that we also have Anchor as well because these are some pretty exciting things where you basically are getting rid of so much JavaScript that you'll never need again because you can simply just use HTML.

And even the JavaScript that you do have to write, like, if you're if you're doing a popover manual, it's really just reference the DOM element, show popover. Reference the DOM element, hide popover.

And it's so simple. It's so Node, and, it, again, it puts it into a top layer.

So you can still utilize it like you would in a a portal.

Another one I end up needing a lot is a drawer. And a drawer JS 1 I'll almost always I say this, but the last 2 times I've needed Wes I built one myself, which is dumb.

I'll use, like, shoelace or something like this. A drawer JS nice because it's something that it's a pattern that's very common on mobile. You'll see it all the time. You click a button, and a drawer slides up from the bottom and potentially has, like, a form. And many times, there's, like, a little line at the top you can click and drag and swipe it down or pull it down to dismiss it.

Reason why I almost always reach for a component for a drawer is there's a lot of edge cases there in terms of how it displays, when it gets larger, how the gestures work, how the smoothness of all that experience works, where you can click to dismiss, those types of things. You know? Like I said, I'll reach for, like, the shoelace drawer.

You sometimes you see drawers pop in from the left or the right or the top or the bottom, but, like, the most common use case for me is the typical one that you see on a a mobile website when it swipes up. Maybe you're, like, buying an app on the App Store. You can see that exact pattern all the time.

Yeah. One thing I really like is when people make their Node drawers on mobile. Yeah. So, essentially, all that is is instead of, like, centering your model, have it come from the bottom, because often you're you're going to be asked to be typing things in and it's nice to be or or you'll have, like, a slider where you gotta, like, adjust the value on there. And it's nice when the action that needs to happen is closer to your thumb, so you don't have to sort of adjust your hand to to work on it. So having a modal that comes out from the bottom, big fan of that. Also, like, it's better than it coming from the side. Like, we're we're all so in love with things sliding out from the side, I think, because that's how the initial Bos was was made. But

think about sliding from the bottom. It's a very native experience to have it slide from the bottom.

Another thing I need all the time that ends up being the same across product to or project to project JS, like, the auth forms. Right? Regardless of the platform that you're using for auth, the login forms very rarely change unless you're doing, like, magic links or anything like that.

So that's something I I've written once, and I take with me from product to product because I I am typically working like a Svelte context. And that way, I could just share code between them all. But, like, really, what it needs to be is the login form and then the text. Do you do you already have an account? Sign up. You click that, takes to another component.

Don't have an account yet? Sign up. Forgot your password? Click here. And it's like the forms are almost always the same, and the only difference is the the API methods in which they're you're hitting. So these these form auth components are are things I bring.

Definitely, I I've written myself because they're not hard, but I bring them from project to project because I I think they're almost always the same. Yeah. Those are are kinda interesting. I wonder if you've seen any, like, interesting

sign up features as of late. You know? Yeah. Like, one of the ones that I've seen and I find this really handy, especially when you're trying to input your email on like like, you go to a restaurant, and it's like, yeah. Do you want us to email you the receipt? And you're trying to type in your email on some, like, Android

keyboard you've never used before. And I'm sorry, Wes. I'm gonna stop you right there. Android keyboards are way better than the Bos keyboard. That's the one I will die on that hill. The Ios keyboard sucks comparatively. I'm not used to the keyboard.

I'm also not used to the, like, Panasonic Galaxy, like, 9 1992 tablet that they're using. Yeah.

Panasonic.

Yarn you trying to type in your email address on this, like, keyboard? So I often love it when they have the at Gmail, or at Yahoo. So and there's just a button because, like, oh, there's not as much work I gotta do there.

You could just you can tap it and and autocomplete it. So I like that as well as I need to do this for my checkout experience as well as the amount of people that spell their email address incorrectly is extremely high. So I'm thinking like, okay. First of all, I need to, like, look for common goof ups. Like, did you did you type gmail and and you meant Gmail? I should catch that before it happens. But also, like, I want, like, a after they submit it, I wanna, like, show them. Alright. We've sent it to this email address, and just give them, like like, 10 minutes Oh, yeah. Where they can correct it. Because, like, probably 10, 20% of my support JS, I bought this, I never got it. Especially, like, I bought this, I'm ready to learn, and, like, hopefully, somebody's around to to do it, either myself or my assistant to do the support, but, it's not always the case. So it's just such a common thing. Obviously, autocomplete fixes a lot of that, but I still see quite a bit of, people goofing up their email addresses.

Yeah. Yeah. Auth forms are one of those things that bug me. Don't make me give you too much information. Don't make me give you my full name or phone number or something. Like, give me the option to just log in with a straight up email and password, please. I have a password manager. It works really well. So, like, I hate it when when auth forms are like that or honestly, I don't like magic links. I'm gonna say Yeah. I'm just gonna like it. Yeah. Magic links.

So a magic link system is a system where you enter your email, and what it does is it sends you an email to log in. You click it. You're logged in. Therefore, you don't have to set a password or anything like that.

The reason they bug me is, like, I don't always wanna have to go to my email to log in. I don't wanna have to to to navigate off the app, especially if I already have an account. If I already have an account, I don't wanna have to go here then go there. I already have the username and password. Just let me enter it, get it in the site. I feel like it just takes too many steps. And if somebody with ADHD in that process of signing up and going to my email, there's a good chance I'm gonna get lost along the way.

Oh, another email. Let me take care of this.

It's so frustrating. So I like the magic link experience when it's something that I don't have to log ESLint to all that often or it's something I maybe I don't have it in my password manager. And the the frustrating thing is that us techies, us developers, we wanna use 2 factor authenticator apps. We don't want text message codes sent to us. We wanna be able to use password managers. We don't want these magic links sent to us. However, the vast majority of the world doesn't use password managers, doesn't use, like, a two factor authenticator app, or they're gonna get locked out of it and they're gonna cause a whole bunch of support. So there's a reason why companies do this because it's it's easier for people to get into to what they're doing. I just wish that, like like, Claude is is one of these. Claude AI. They sign me out, like, every 12 seconds. Like, I feel like every time I use it, it signs me out. Now I gotta type in my email address. I gotta wait for the email to show up, and that's sometimes, like, 30 seconds. So I'm just kinda sitting there. Gotta wait for my email client to refresh itself.

And then finally, you get the code. You gotta copy the code. You paste it in, or you click down the ESLint, then you got to delete the email. Such a pain in the butt. I rather just auto one password automatically sign in. Passkeys, obviously, gonna

solve a lot of that. I've been seeing a lot more passkeys pop up recently, and I'm really happy to see that. But yeah. The the last thing JS just give me an option to do an email and password if if you could. The the time I like the magic link the most is when I'm writing the authentication system because it's easier to do, and I have to do less work.

So it's I I don't like it as a user. I like it as a developer. Let's talk dialogue and modals. Dialogue and modals are something that we need all the time. And now with the advent of HTML dialogue and modals, it's going to make our dialogue and modal components much easier, at least easier to write. So you won't have to do the whole portal and come up with your animations and write your your state for these things. You're not just gonna be able to do it with the the HTML versions of this. So you know what? I do end up even writing a wrapper around dialogue in Node. I I usually end up doing this just because, hey. I like to have my own interface guidelines where I have buttons, how I like the things to work, how I like the things generally to be styled. I'll wrap up the styles in that. So I will typically almost always write my own dialogue component, but there's a lot that can be done with out of the box ones for you.

Yeah. I feel like the dialogue in modal so dialogue is something that will pop up on the top layer of your your website, and then you can also have the option to make it a modal, or you can open it modally, meaning that you can open it. Instead of it being a part of the context, it will just overlay the whole website and make the rest of the website the word is inert, meaning that the rest of the website is not clickable.

It still is scrollable, which is a bit odd. I hit that yesterday, where you still have to disable scroll bars, but you can do it entirely with CSS. You could say when the HTML has an open Node, then overflow hidden on the, HTML element or or on the body.

And it's nice that you get the backdrop property now so we can style what it looks like behind the Node instead of having And you can have an animated. Div. Yeah. It's it's amazing. Like, you could do a modal with very little JavaScript. The only JavaScript you need is to open it. You can close it with a with a with a formal update.

Yeah. Yeah. But you probably still want to hook up, like, a button to close it, but also, like, the escape is already bound. You don't have to do this weird, like, global listen for escape. But then if it's not open like, usually, what you do is you listen for an escape or you listen for a key up. You check if it's an escape. And then if it is an escape, you check if the Node JS open. And if that is, then you add it like a close button. You set some state. You don't have to worry about any of that anymore, which is it was pretty sweet. And it's in all the browsers now, isn't it? Yeah. And it's it's great.

This is yeah. I don't know if you missed this, Wes, because I actually missed it even though I probably retweeted it at some point. But popover, which came later than dialogue.

Popover JS in all the browsers. We don't just have the dialogue. We have,

popover now and everything. So what's the the difference between pop over and dialogue?

Cool. So okay. Let me tell you. Pop over is you can make anything a pop over, and it really just happens to be an attribute that you put on something. So let's say I have a, like, I made my Toast message system that I built recently using popover.

So I have the wrapper that all the Toast messages appear on. It's a div.

In that, I have a property or an attribute of popover, and that can be set to either auto or manual. Manual means you have to open and close it manually.

Auto means that if you click off of it, it will close itself. That's it. Click outside.

But that's all you need to do JS you give something popover equals auto, popover equals manual, And then when you call JavaScript to show or hide that popover, it puts the thing on the top layer, and it makes it visible.

If it's hidden, if that pop over is hidden, it makes it invisible.

There's some interesting CSS properties around this too, Wes, that we can talk about later, like transition behavior, allow discrete. Have you ever heard of that? No.

Yeah. We'll talk about more about that, but it's how you can animate certain things that you couldn't have animated before.

And Like, despite know we Wes did a show about pop over a while ago, and, like, I was getting into, like, dialogue and modal yesterday, and I was trying to think, like, like, when would I use a popover, and when would I use a dialogue? And it seems like like popover can be open and closed entirely with HTML, which is Yes. I just said, not the case with dialogue.

Yeah. Popover is is simultaneously, like, it's less work, but it's also lower level than the terms that you can make anything into a popover Wes dialogue maybe is more useful for modals and dialogues and alerts, those types of things, where popover is just really anything that you wanna pop on on the top layer. Mhmm. And once we get CSS anchoring, we'll be able to do tooltips

with popovers as well. Right? Or, like,

little user menus, little menus, and pnpm things Dropout menus. Oh, man.

Anchor anchor is like the one that I I had to write my own, like, you know, JavaScript to do anchoring for me. But we have anchor in Chrome. It's not anywhere else. So hopefully we get that soon. Another thing I end up writing a lot is confirm, like a confirm system.

And, you know, it depends on how you want this to be. I have, like, a Yarn you sure about that button where you have to click it an x amount of times. I have to click this 3 more times. It tells you how many times you wanna click it. That's not something I'm gonna give users typically.

But, you know, the confirm button typically works just like you click delete on something and a modal pops up, and it's like, are you sure you want to do this? Yes or no? Yes. Okay. Let's go. So that's like a 2 step verification process. A confirm button is usually a a combination of a button that triggers a Node. That modal pops up. And if you hit yes, then that runs the action of the initial button. And I usually wrap that up into 1 component. Confirm button, here's the success action. Here's the cancel action. Here's the text. Here's, you know, any sort of properties you might need. Just wrap that all up into 1 little confirm button component.

I've I've written my own confirm and prompts based on promises with the the new deferred with resolvers.

And it's really cool because, like, it's obviously easy to use prompt and confirm in the browser, but those UIs, they it first of all, it doesn't look good. Second of all, like, it's it's kind of frustrating to you can't style it. You can't prepopulate or you can prepopulate data, but they're very limited. Right? So I've written them myself with the dialogue where you can you can put an input in there, and then you can just wire up the buttons to confirm, or cancel. Those can be resolved and reject, and then you can also pass the data if you have an input in there, which is pretty nifty. So those are a fun one to build, especially if you wanna, like, get some some promise exercise, doing something with promises that is not fetching data waiting for it to come back, because it could also be simply just waiting for a user interaction.

Let me even just say this, Wes, because I think this is a good good thing to say as a part of this conversation.

If you wanna become a better developer, take this list of common components that we're talking about and just go 1 by 1 and build them all. Because so so many times, everybody just grabs them from, you know, this library or this library, this library, and that's great. For productivity, great. But if you want to really get into how do I become a better Reactors, Svelte, or Vue developer, implementing these patterns will make you a better developer. You'll get to see exactly how this stuff works. You'll get a lot of experience, and I think that's a good good technique to do at least once or or twice in your your dev life. A component I really like that I don't see often talked about JS, like, an admin menu.

If you are logged in as an admin, I show you the admin menu on the Sanity website.

And this is just my old habits from the days of WordPress and Drupal where I had a little menu that took me anywhere I wanted to go with any of the admin tools. I wanna go here from here. You Node, your site admin or your site navigation doesn't always include all the links in your site or the places you might wanna go. So, again, if I'm logged in, I almost always have an admin menu. I built mine. I'll I'll show it to you in the Svelte repo here that you can check out. But it it's really handy. That Wes, you're not always reaching for the URL bar to type in where to go. You can just

alright. Let's go. Can while we're on this, I sent you a pull request, like, 2 months ago. Okay.

For your Svelte Svelte menu.

Yep. Let's merge it live on air here. Yes. I'll do it.

It was it's like a Svelte 4 upgrade path or something like that. It's like a warp it's throwing a warning if something is gonna break soon. Yes. Fixed it. But it has to see that. Okay. Cool. Be upstream merge.

There it is. And deploy anyone. This is this is also why I love the whole copy paste, component renaissance we're having right now because if that component was just a component in our code base, then I coulda fixed it. But Hey, Wes.

Yes?

Let me tell you. I thought about this deeply.

I thought about this so deeply, and I gotta say, I came up with a solution, and I I'll I'll talk about it right now because we don't have a ton of time left in this episode, but we can talk about it more later on another episode.

I built a system that has it's based off of a old Meteor feature that nobody else has really done since Meteor.

And in my starter kit that I'm building, I have a packages directory that lives inside of source. Source packages.

Inside of that are all of the local packages.

And to essentially have your own version of any package, you just put the package in there, and then it automatically becomes part of the workspace.

And just like a shad CDN component or whatever that you're bringing into your own site, you're bringing in packages and throwing them directly in there. Now this kind of falls apart the moment that you get into, really deeply compiled local packages.

But in the Svelte world or even in the React world, you don't necessarily need to compile that sucker if you're consuming it. So you could link direct you you could bring in a package like a Svelte package. You could maybe modify the package Scott JSON to point to the Svelte file itself that you wanna change.

Just change it right there, and it's not trapped inside of node modules. It won't get overwritten when you do the NPM install business. Yeah. But then the site site can recognize it as if it was the normal package import itself.

I don't know if this is a gray pattern, but it's from Meteor, and I really liked it there. And working with it right now, I think it's kinda neat.

So I'm gonna explore it a little bit. Like a it's just some like a that's essentially just a monorepo. Right? A monorepo. Yeah. Yeah. It's a monorepo, but it's the monorepo stuff is included as a part of the app. And instead of like, the way most monorepos are JS you have the monorepo, and then you have all your different app packages. This is like, here's the site. Here's the app. And inside of that are consumable modifiable local packages. Yeah. It's so like

ejecting. You know? Like, I wanna tag this package.

I think about it like a WordPress child theme JS what I think about it like yeah. Okay. But, like, Wes like a child theme still uses the parent theme, though. If you're ejecting, you're, like, you're abandoning all

future updates and all functionality from the parent. Right? Yeah. I guess this is more like copying a theme and then having it. Yeah. Yeah. Exactly. Yeah. Alright. I also use a mobile only and desktop only component sometimes, and these are really just presentational.

They could be done in classes as well. And and maybe the mobile only or desktop only is just showing and hiding based on breakpoints.

That's something I I tend to have just nice and easy. Client only is a component that I'll have frequently, which is basically, hey.

Only do this component if the browser exists.

If document exists, then therefore render this component.

And that's something I I tend to tend to need an admin table. If you have any sort of back end, typically, you're gonna have a big old table of all your data, having a Scott, search, filter, and then maybe, like, being able to set actions in the columns, like delete the transcript or import this or that or whatever. I end up building those a lot myself.

Yeah. I wanna extend our we have, like, a a pretty beefy little admin table that just takes a I I oh, that's that's 1 I've built probably 7 or 8 times.

The dump component.

I've I even I published it on npm. I think it's called I think it's just called dump, and it will take an object and loop over the keys.

And depending on the type of the value of the key, it will like, if it's a number or if it's a date, it would just display the value in a table, but then it's recursive.

Meaning that if you have an object and nested an object, it will just go forever.

And I've often thought about being able to, make that editable as well. Dude. But then at also at that point, you're essentially just using, like, what's the Prisma thing to edit your data directly?

Yeah. Let me tell you. I built this. I built this exact thing that you're talking about, and it is an extension off of my Svelte slide menu.

And, again, it was based on a meteor package, meteor toy.

And, again, what it does is it loops over all the data, and it just makes them data inputs. And the way that Svelte reactivity works, I don't know if I'll have to I'll definitely have to change this for ruins. But the way it worked is you just update the stuff. So I just made it all inputs, put the thing in, put a bind to the value on there. Bingo. Bango. You have editable data that you can edit in the side menu as a dump, and it updates it on the site. It might not update in the database, but it's gonna update it right there in the Bos site or so I'll give you,

you know, global state toggles. It's like a dev tool. I like it. It's there's probably a Scott of edge cases where, like, oh, then you have validation and Number values and sliding. Values and Yeah. Wes, how do you convert back? But, like, there's a lot of, like, common use cases. Like, we had the Totally. The other day, I I wasn't in the chat, but, the AI the descriptions on the syntax of every episodes generated by AI.

And it had, like it switched centrally with Sanity, probably because we have a I give it a list of, like, commonly said words, and it must have switched the one.

And we're like, oh, crap. Like, we gotta edit that quickly. You know? And we didn't have a way to directly do it, and CJ went straight into the database and changed

it. Yeah. We gotta have it. That's on our to do list. Another component that I end up writing a lot is a share and social links. The share API within the browser is a total mess, so good luck there. But you can check out what we do on the the syntax site for a share component because, you know, typically, what I do, even though the share share permissions or or share, feature exists in the browser, it's every browser handles it so incredibly differently.

I'll pretty much always say if mobile, then use the native browser share functionality because the mobile native share functionality is good. And if it is desktop, here's a bunch of, like, the share links when you click a link and it's a link to create a tweet or something like that with the URL instead of using the native, functionality because I don't know why they fail so hard on that. But it feels like there should be a better solution, like Bos wide,

to handle shared dialogues on desktop. Yeah. I agree. It's it's not great. And, like, that, there is a good use case for, detecting if you're on mobile. It's a great shared It's the worst. Like a code snippet from that file, where you're trying to detect if it's mobile or not. Yeah. And I got roasted because people were like, you're not supposed to feature detect or Node. You don't tech for devices. Check for features.

And that's a case where, like, it has the share feature, but it sucks. So you have to check like there's no there's no function called check for sucky share features, you Node. So in that case, you literally have to check if it's if it's an Bos device or not. Yes. That bugs the, that bugs a ton bugs me a ton. In fact, I have a whole video

on that exact conversation in my exploring browser APIs series that I'm releasing on YouTube right now JS a level up Yeah. Series.

But it was a whole thing. Why do we have to browser detect for this when we should be feature detecting for this? And what are the pitfalls here? Why user agent is a nightmare to have to detect off of and, like, what we can do to to to solve that. Alright. Let's rattle through a couple more here. I use a markdown renderer very frequently.

Just render markdown, take a take a markdown in, render it. Sometimes I do that server side, but many times I'll just pop it into a component.

Tabs, we have tabs on the syntax, say, for the transcripts and stuff like that. Sometimes tabs need to be changed with routes. Sometimes they're just straight up tabs, but I hate tabs all the time. A user menu, so it's like the avatar. You click on the avatar, it drops down. Maybe there's a link to profile or whatever and then a logout button. Need those all the time.

Icon component, I know icon components are, you know, controversial in many ways, but oftentimes, it's just a pickle switch statement of different icon options that you can have. React, that's a bit more of a problem than in other ecosystems.

A loading

component usually just Why? What can hold on. You're people are probably wondering why. Why is that a problem in React?

That's a great question.

I've just been told not to do it in React. And since I don't write React, I don't really know. I would assume it's because of how it's rendered

repeatedly. It's the the reason people say don't do it in React is because an icon is SVG, and it is put into your bundle. So if you have a whole bunch of icons, then all of that SVG is going to be put into your bundle and it will make that bundle large, especially if you need to download that whole bundle first.

It's the same case in Svelte. We we do this. We put our speeches in a file, but I also don't think it's an issue. And our Svelte site is really good at just requesting them as needed.

So I don't know if it's it's really that big of an issue. The whole, like, where should icons go? And if you need to change the color of them is always such a tricky thing. You know? Like, obviously, it's nice to just use the image component, but then you give up the ability to do,

changing the fill. Which is, like, almost what you need all the time. Like Yeah. I I get there Yarn just fill

Yeah.

On a image tag?

I know. Yeah. That to me is is one where it's like, am I going to need to change the icon color? Most likely, especially, like, to dark mode. Is it just a straight up SVG that's not like an icon? Then then that conversation becomes different. But icons, yeah, I almost always need to render those out.

Loading components usually just either for me, sometimes just an SVG with an animation or just sometimes a CSS animation, but it's nice to be able to just drop a loading component. Maybe that loading component shows up automatically on its own after a delay time a certain amount. I mean, you can juice that up a little bit to have it be a little bit more interesting than something you're just showing and hiding based on a state value. Yeah. But I like the ghost loaders a lot.

I I feel like I need to put those those into my application a little bit more. I prefer a ghost loader that kinda gives you a bit of context for what will be showing up rather than just a a spinner.

Yeah. You know what grinds my gears about? This is the grind my gears episode.

Grinds my gears about ghosts is when, like, the layout the ghost layout shows up, the skeleton layout or whatever.

And then when the actual content loads, it's, like, not in the same position or the same layout. Yeah. I like the real content to show up in the exact spot and, like, fade in on top of that. That. Otherwise, it just feels lazy to me. But yeah. Yeah. Yeah. You kinda have to Node. You kinda have to have, like, a pretty well defined structure. Like, if it's a blog post,

you might not know Mhmm. What the the skeleton is going to look like until, until you have the content on there.

Yeah. For sure. Drop down menu JS very similar to the user menu. Usually, 3 dots. You click a drop down menu. It's a perfect place to flex your popover skills, but also gonna be way easier with the anchor positioning. And lastly, but not leastly, I think this is one that most sites use, an anchor or an accordion not an anchor. An accordion animated accordion. Also, way easier now that we have the details in HTML.

Yeah. Yes. But I've never element.

Can can you style details now? Because I've I've always, like, use details. It's like input type of date.

Yeah. Ugly.

It's there, but oh, no. I'm just looking at I'm looking at the example here on MDN. You can style it. Yeah. You can style it. Can you animate it?

Yes. You can animate it, but I don't think it's as easy. You know what? Like, I feel like you should just be able to at this time, there's no way built in a way to animate the transition between open and closed. Yeah. But I think you have to I think you can do it with JavaScript is what I'm saying. Like, you have to, like, really

Oh, yeah.

Yes. See, that's why it's nice to help out. Way, which would be nice. Yeah. Yeah. I agree. It would be nice to, like, go a little further on those types of things because, like, I feel like a lot of these, like, early custom components we got in the browser, it was like, oh, these are awesome. We finally have input type of date. That's always the one I keep going back to, But nobody's going to use it because it's not very good. You Node, it's okay for a demo or okay for a little admin UI if you just need a quick one. But if you actually want a nice experience,

then you're gonna have to reach for a custom one. And accordions are, like, really painless to build too. Again, that's a great one to build. The hardest part about building an accordion is the animation part of it. But even then, because you have to do, you know, animate 0 to auto.

But Svelte makes that really easy. Guess what you do? You put a transition slide. That's all you do. You don't even have to think about it. You don't have to write any CSS. It just works.

Sick. Well, that those are the common components that I feel like I need and maybe, grind it you know, what kind grinds our gears a little bit about each of these components. But I do think this is a great road map for you to really understand interface development, maybe some common things, what works, what doesn't, why things need to be complicated here or there, which things you can build your own. And, honestly, sometimes the best tools are the ones you you build your own, and sometimes the best tools are the ones you just import and, call it a day. So, let us know what are tools that you end up building yourself every time because you don't like the ones that exist in user land? And what are some tools that you always take from user land? Let us know in the comments. The best place to reach us is on YouTube. So hit us up at youtube forward slash at syntax fm. Leave a comment on this video and let us know.

Let's get into the part of the show where we talk about sick picks, things that we pick that are sick, things that we like and enjoy, things that are just vibing with us right now. I'm gonna sick pick a book, Super Communicators. I just finished this book, and I found it to be really nice. You know? I I'm a self help book kinda guy. I like self help books. I think I may have talked to even about this book on the show before. If I haven't, this is, this is a great one to check out. Super communicators to me was something that, like, now that I've gone through it a couple times and have, like, really taken the time with it, I do think I'm going to approach most conversations in life just a little bit differently.

Certainly, we'll approach arguments very differently whether that's online or otherwise.

You know? Just I I I found this book to be really great. And and like I said, if I have mentioned it on this show, just know that this is a a double down on that that pick.

I'm going to sick pick something that's gonna make all the mechanical keyboard folks very angry.

It's an app called Clack.

And it sounds so stupid, but it's so good. It's a it's an app that makes mechanical keyboard sounds as you type. That's great. And I first installed it as a joke because I was like, oh, I'm gonna record a couple of TikToks and, like, it'll make me look like a like a pro with, like, a really loud clickety clackety.

And I turned it on, and I was like, I really like this. This sounds nice. It makes me feel calm for some reason as I'm typing. And I have people get mad because, like, I have lots of Mikael keyboards. I've tried them all. It's it's not for me, at least not right now. You know? I'll I'll try it again in in a while, but I just like my Apple keyboard. But I like the sounds that it makes. So if you want cool sounding click clack as you're typing, they are different sounds for every key.

And a lot of people warp complaining about latency, but it's it has no latency for me. And I'm even wearing Bluetooth headphones.

So check it out. It's like Bos. But then also a couple of people recommended this other one called Mech Vibes, which has all, like, hundreds of sound packs available, so you can download. This one only the one I use, Clack, has, like, 3 different types of keyboards you can choose from. But this one has, like like, a 100 different keyboards that you can you can download sound packs for, and it is free and open source as well, which is probably a good thing if you're installing a, like, a key logger, on your system.

Yeah.

Oh my gosh. That's that's wild. I cannot say I I would reach for Node of these, but maybe I'll give it a try just for fun.

Try it. It's I don't know what it is, but just I love it. It makes me feel more productive and

focused and calm. I don't know. Yeah. That's sick. Cool. Well, I'm gonna shamelessly plug the YouTube channel, youtube.comforward/adsyntaxfm.

Again, not only are we releasing every episode as a video episode, which is fantastic.

We're also releasing Vercel up tutorials premium content from the, that was behind the level up tutorials paywall. We're putting it into playlist. And CJ is releasing videos every week. The latest one is all about setting up COOLIFY.

And, wow, he did a straight up, like, deep, deep, deep dive into into COOLIFY, and it is really fantastic. So if you want to get all that and more, check out youtube.comforward/adsintechsfm.

Wicked. Alright. Thanks, everybody, for tuning in. We will catch you later. Peace.