Components We Need on Every Project

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. 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.

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

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.

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,

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?

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.

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 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

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,

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.

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.

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 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.

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

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.

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.

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.

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,

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.

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

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.

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

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

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

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. 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,

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,

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

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

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

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.

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,

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.

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

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.

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.

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.