How To Do Things In Svelte

Monday. Monday. Monday.

Open wide dev fans, get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest, the craziest, the tastiest web development treats coming again hot. Here is Wes, Barracuda,

Boss, and Scott

CSD. Welcome to Syntax.

In this Monday, hasty treat, we're gonna be talking about Svelte And how if you are a React developer coming to Svelte, what are the ways that you can do many of the common things that you're used to doing in React? So my name is Scott Talinski. I'm a developer from Denver, Colorado. And with me as always is the West Boss.

I am excited for this episode because I've been dipping my toes into some more Svelte here and there. And then I have also been going back into my React projects, and this is not gonna be a beat up on React episode. We've done that already.

But we do want to do an episode of, like, common things you want to do in in an application. And here's how you do those in Svelte. And Spoiler alert. It's very simple.

Yeah. Yeah. I thought you were gonna say I'm feeling very sleepy because we are both, Feeling that parent life this, this Parent life day. Morning.

Dog dog dad. So my, like, My kids were up, like, 3 times last night, and then our dog just starts barking in the middle of the night.

And I was just, like, Whenever that happens, I flip on our I open the app on our phone and check the cameras, make sure there's no, Drug enthusiasts or something like that if you're knocking on our door. But,

there wasn't. It was just our dog barking for some odd reason. It's Kind of annoying. They're replacing, like, all of the city pipes on our on our block, in our neighborhood, and it's been taken, like, a week. I mean, it's taken a long time because, You know, there's a lot of pipes they gotta dig up, but which is great because they're no longer gonna be lead pipes. Thank you. Oh, yeah. That's gonna be fantastic. But, we've been sleeping with the windows open because it's, like, perfect weather for that, and it just so happens that yeah. Any any noise and Lucy, us. Our our little guard dog, she goes nuts in the morning, waking us up at, like, 6 in the morning when they they start the construction stuff. So Man, I feel you, man. Digging up the road is so disruptive so So disruptive.

Do you get the, the line to your house replaced as well, or is that have already been done yet? Yeah. They're replacing everything, which is is gonna be fantastic for us because That's awesome. We were not psyched about the lead pipes. I have a funny story about, about those, like, water pipes. So, we when we moved into our house our house has has lead pipes and, we didn't know it at the time so we just kind of whatever. It.

And we built, like, a little retaining wall in the front of our house. And, there right where we wanted the wall to go was the, like, water shut off. Oh, and, I was like, when we put the wall up, I'm just like, do you really ever need that? Like, half the time you see It just cemented into people's driveway anyway.

So, I was like, you know what? Whatever. And we just covered it over, which is Oh, no. In hindsight is awful. And And then, like, like, 8 months later, we go to get our lead pipes replaced.

It's it's a common thing. Every house in in our city needs to have the it. The line from the street replaced.

And they they come, and they're like, we can't find your Oh, no.

You can't find your shut off anywhere. And I was like, oh, man. I think the landscapers might have covered it. Yes. I'm an idiot. So he's like, I was like, oh no. Like, are we gonna have to take this whole wall up? He's like, oh no problem. We'll just put a new one in when we do the line.

Anyway, So luckily, it was not a big deal. They just put another one somewhere else in in our front lawn, but I was I was freaking out there for a second because

So don't don't cover those things. Yeah. Yeah. The dumb things that you do in homeownership.

Yeah. It's fine. Whatever.

Yeah. I have no clue. The dumb things that you get to experience that someone else did.

Well, when we got our lead pipes replaced, our, like, water pressure a shot up, and we have, like, the best showers ever now. Heck, yeah. Alright. Anyways, this is this is too long of, talking about lead pipe talk, and, it. Let's get into some sponsors. We've got 2 today, FreshBooks and LogRocket.

Let me talk to you about FreshBooks. It's cloud accounting for your small business, for your large business, for your freelance for whoever is just sending a couple invoices out. You can do your invoices. You can do your expenses. You can log your time.

It. You can import everything from your bank account. It's the best way to manage your online accounting. Check it out. Freshbooks.comforward/syntax.

Make sure you use syntax. And the how did you hear about us that's gonna get you a 30 day

free trial. No credit card required. And this episode is also sponsored by LogRocket at logrocket.comforward/ syntax. LogRocket is the perfect place to see all of your errors and exceptions happen in a scribble video replay. And you know what? Let's actually had to use LogRocket, this weekend because, the time we're recording, this is like the Black Friday sale. Kinda is ramping down today's Cyber Monday that we're recording this. So it. I I had a a little issue, and it was so bizarre. It was a weird little bug where 1 user in particular was not able to, get their credit card information to go through, and it wasn't a decline. It was not even reaching my payment processor. And so I said, okay. This is the perfect Opportunity for me to use LogRocket. So I fired up LogRocket, and I could see, what the error was that they're seeing.

I was able to look into their user account, and I was able to actually see the console error message that was coming back from the network request As it happened, and it led me to realize that this particular user had kind of a a weird account from is an older account, which had some interesting old data in it, which is something that can happen with MongoDB.

And, I I just had to clean off 1 property in his It's user object, and then everything just worked totally fine. But a totally odd bug and not one that I've ever hit before, and LogRocket was the perfect Cool for the job. So thank you so much for LogRocket. Give it a check. It's a video replay for your errors and exceptions. Logrocket.comforward/syntax.

Alright. Let's talk about Svelte.

If you haven't listened to the past, episodes about Svelte, Svelte is a Svelte and SvelteKit. Svelte's not new, but SvelteKit is pretty new.

And you can kind of think of Svelte as React and SvelteKit as Next. Js.

It. And it's a new JavaScript framework library, whatever you call it, for building web applications.

And, Scott and I, Scott specifically, has turned me onto it. Scott went absolutely bonkers for it and rewrote his entire platform in it. Right? You bet. Yeah. And then I and then I did a conference talk on it at a salt summit if you wanna watch wanna watch that to learn more about that. That is amazing. And Scott it. Scott was so enthusiastic about it. I decided to try it out and build a couple things in it. And boy, oh, boy, is it awesome. So I thought we'd do an episode that just kinda goes into the major pieces of building an application, local state updating, reactive, conditional rendering, input binding, and child elements.

There's certainly a lot more to it, but these are your sorry, your fundamentals.

And we'll just go into how they work and and whatnot. Yeah. It's definitely the stuff that you need to do in just about every app. Right? This is the normal stuff. So the the very, very first thing you ever do when an app is Get local state up and running. Right? If you're learning a front end framework, I remember the Angular one example would have been like Their first little blurb about Angular, it was a like a local state kind of example. So local state in Svelte is as simple as setting a variable and then updating that variable. So instead of having to use like a function like in react, you would have a Use state hook that then creates the state variable and the state updater function.

And then to access the current state And then update it, you'd have to do a callback to access that currency. You don't have to do any of that. You just have a variable. Let's say, the variable name is, who is the coolest person ever, and it's set to Scott, and then you wanna update that to say, no. Actually, the coolest person is now Wes. You could say coolest person is now equal to Wes, And that actually automatically updates the UI for you without you having to worry about render cycles, the current value of anything. Because when you're accessing that variable, That's the current value. You don't have to worry about

what what does the state think the value is. You just think about what is this variable set to right now. That's one weird thing about React is that, like, I tweeted a little code snippet the other day where I was, I'm redoing my course player in in React right now, and I'm going, like, between widescreen and not widescreen, so I just have a variable, widescreen true. So I I use state, And then I create an updater that takes the current variable of widescreen and just flips it so that it's true or false, true or false. Right? Just a simple toggle function to turn the variable on and off. And I got, like I tweeted it, and I got, like, 8 people being, like, you should actually use the callback, like I know. Right. To update. I was, like, you need a callback x function to flip a variable. Come on. And and also has that like, one thing that I've talked about in my courses

is that, like, yes, they tell you this is the best practice, Has there ever been a situation where you end up getting the wrong version of the variable and it gets confused,

Especially for a simple toggle like that. Yeah. I've I've certainly run into it. But Yeah. But with As like code. Stuff or or No. Like it.

Like, if somebody were to hit the button so fast that they were out clicking the event loop Right. Like, their finger is faster it. Then the event, like, come on. That's not gonna actually happen, like and that's not all all wrecked. That's, like, I know I know why people need the callback, and I know when to use it. And I decided not it. Use it there because literally never gonna happen.

But it's I think that's the people that have, like, sort of rules about specific things. I I was gonna say, that is the problem with so many of those, like, react best practices articles is that, like, they're so devoid of context sometimes, and it's like, just do this, Do this. Do this. Do this. Whether it's on, like, here's here's the actual concern there or the level of

Issue. Same thing with, the arrow functions. I showed, like, a component being export function Search component. And then someone's like, why are you not using an arrow function? I had a couple of people say, I'm like, what? Like, why would I like, what's the benefit of using an arrow function there? Let no. Someone chimed in with the the I don't can't use this inside of it, but they just don't use this then. Yeah. If you're not using this, then it doesn't matter. There's no benefit of that. I think, like, we've talked about this a few times where, when we got Arrow functions, people sort of swung over to them as, like, these are the new functions and Regular functions are deprecated, but that's that's certainly not the case.

Yeah. Yeah. It it it's so funny because I the I think the biggest thing about moving to You're no longer worrying about what React is thinking about. Like, some may or, like, what what does React want? What is React Thinking right now, I don't have to, like, try to read React's brain, because you're just looking at the variable. It's not like, what does Svelte want me to do? I don't know. This is just JavaScript. Right? It's a variable. We've changed the variable.

You've updated. Alright. Next one.

Functions that update state.

So I'm gonna let you answer this one. So say you have a variable called score. We just talked about how making it, but you want to have it. An updater function because that function has some sort of logic inside of it.

A very simple example is, let's say, you wanna increment Of course, you could just update the variable directly. But what if you wanted a a custom function to update that score? I'm I'm curious. Like, what would your approach be Both if you just want a single instance of that across your entire application, or you want to have multiple instances

of that score variable and have updater functions for each of them similar to how a a hook would work and react. So, basically okay. So the well, actually, let's answer the first one first. If you just have a a single state variable and a function, you wanna update that function, you could just have it be a straight up variable and a straight up function. If it's in that DOM tree, you can pass it down as props if you want and then bind if you want to change it Later further down in the tree if you want, or you could pass the function down just like React. The thing I like about Svelte is that many of the React patterns if you want to use them. They're there for you. You can pass an updater function down if you wanna do that, or you can have the child update it with a bind function.

If you want to have these things available just sort of outside of a a Svelte component for importing or something like that, you could take a A writable store, which is basically a subscription where you subscribed to a variable, and then you can update it.

You can create custom ones where you have your own functions and advanced reducer logic and things like that. So you you can certainly Stored in a Svelte writable, or you can have it as a normal variable on function and pass it down. As for the the hooks approach, there is a Sort of use state pattern that ends up being basically this exact same type of deal. In fact, somebody even made a React hooks and Svelte repo, c s, which reimplements any of the React Hooks. If you really like working in React Hooks, you can you can see what all of those actually end up being like. But the end result is really that you were just creating a state variable in hooks, and you can compose the state that way. Let me It's so hard to to explain these things on a podcast. I'll find a repo and post it. Yeah. We'll link to it. We're not gonna do any mouth coding on the Yeah. On the podcast here. I I think I got it here. It's called React Hooks in Svelte. Yeah.

That one doesn't show you exactly, but it it it shows you good examples. So that's, like, a a good linker. Next one we have here is live and reactive variables.

So by default, variables in Svelte are Just live, meaning that if you put a variable into a string or into some HTML or literally anything, when that variable updates, Then Svelte will rerender with that new value. And that's really, really nice. And I really wish that, vanilla JavaScript really had something like that, because right now, you just have to rerender whatever HTML is in that. And that's kind of nice to be able to just use, that specific value.

If you wanna go a little bit further and maybe use that value in another like, a calculation, Maybe you take someone's age and you multiply that by 7 because you want to calculate dog years or some some silly thing like that. With that, it. You just put a dollar sign in front of it, and that shows felt to watch, for those values to change, and it will update the values for you. That's that's right, Scott. Right? That's correct. And there's other ways you can do that too if you have, like, a subscription. So let's say you had a Svelte writable store or a readable store, and you wanted to

Have a derived store available from that. There's, like, a derived, function that can create a derived store as well, which is also a very similar technique Because you're basically saying, hey. Anytime any of the information in the store changes, update this derived store as well. But So I end up if I'm getting, like, reactive stuff based on something else, I'll I'll use a reactive statement or I'll use A derived store depending on what that incoming data is, but what what's really nice is that you can use those in any sort of block capacity too. So if I were to say dollar sign, colon, and then 2 brackets and just create a new code block, Essentially, anything in there can then become reactive, so you can do a whole bunch of stuff when in what is essentially a useEffect without having to worry about what the dependencies are or worrying about the render cycle for any of that. So that That's really great. One thing I I I think the reactivity in Svelte really nails is is getting rid of the things that you have to, Like, worry about, like, console, counting rendering cycles, worrying about infinite loops. Those types of deals are are way harder to do it in Svelte with reactive variables Just because there's just a way to do it, and you don't have to program the dependencies or anything like that yourself.

It's it's just baked in for you. Next one we have here is Contacts. So contacts allows you to, pass data between components without having to manually pass them down. And that's That's very helpful in in lots of applications because, you can write a component and you can say, I know that this Usually, when you make a component, you can say this component will render or this component will work given that you pass in the following data.

But sometimes if you have Very nested deeply application. It's hard to to pass that stuff down all the way down. So what you do is you stick that in context high up in your application, And you're sort of able to just grab it out of the air, so to speak, with, with React Context.

So, Svelte React obviously has context APIs. Svelte has a context API as well. I'm curious. Like, do you use that, or do you just import and export stores in most cases?

I know I never used the context API, really. I pretty pretty much only use stores in that regard. Yeah. Stores are really easy. I have basically a a, like, a global state folder, that has, an alias path to it that's just state. So if I want to let's say If I wanna, let's say, toggle the loading state for the entire application, all I do is say dollar sign loading equals true after importing that in because What that does is it basically gives you a reactive variable throughout your entire application.

So instead of having to worry about Where's the parent? Where's the child? What what kind of context exists in this thing? You end up being able to say, Oh, I I just have this reactive variable, and anywhere I use this thing in the entire application, just have it be reactive. And when I change it, Just have an update. And, when I set it updated or whatever and and some people get a little bit scared about that because they feel like it could be too willy nilly. But You can if you wanna, lock it down more, you can create your own custom stores with your own updater functions. So if you don't like changing a variable, You can have an updater function that changes the variable. You can have a reducer for it. You can do any of the same stuff you would with context if you really want, or you can just have a Dollar sign loading is now equal to true. Alright. Dollar sign loading is now a go to false, those types of things, and have it working for you. We have this all over our application, and and pattern scales really well, at least for us. And, well, actually, one thing it allowed for us to do is build, like, a little state updater tool that we have called Svelte Toy that you can check out where you just pass your stores into that, and it turns them into reactive inputs on the sidebar, and you can change the state of your application at any given point just from the sidebar without having to worry about parent, child, any of that stuff. So I'm into it. I'm just reading the Svelte docs here. It says context versus stores. What's the difference?

They said, they differ in that stores are available to any part of an app while context is only available to component and its descendants.

This can be helpful if you want to use several instances of a component without the state of 1 interfering with the state of others. In fact, you might want to use the 2 together since context is not reactive.

Values that change over time should be represented as a store. So If you need something that is a not reactive, you could use context as well. Yeah. So context explicitly isn't reactive, but storing a

A store in context would be reactive.

Interesting. Yeah. That's they're kind of minor difference. I could see how you could probably Get away with, it looks like the Flexbox versus Grid kind of thing where they have lots of overlap and some Differences here and there.

Yeah. So next one would be, conditional rendering.

And, conditional rendering is actually really pretty neat. We're talking about it like the template. Let's say you have, like, some information. The the most common, ways that you see this is, like, if something's loading, show a loading screen. Otherwise, show something else. Or maybe you have, like, a a model that says if this variable is set to true, then show model otherwise don't. So that the very most basic, you have a pound if and then the variable, and then anything inside of that bracket is going to be shown.

Now you can also do a colon else if or you're just a colon else, and then you wrap it all off with a forward slash if as the canceling the template tag. So at its very most basic, it's just a if condition show thing. Otherwise, maybe other condition, whatever show thing.

Now there's also some really interesting promise based tags and even like another one that I don't think the people really think about. So if you do pound await And then a promise. So let's say you have some data that's coming back from an API. That's a promise. You could say pound await data, And when that data is unresolved, you can show a loading screen, and then you can say colon then what does whatever the variable name of the results will be, And then you can have your result in there. So you can await a promise inside the template itself, which is really super handy.

It's something that we've used quite a bit. Now another cool thing about the pound await is that you can use it with Svelte stores as well. So when there's The store data resolves. You can use it as well. And you can That's really cool. If you don't wanna show a loading screen at all, like, for instance, this is for, like, a server side situation or something. You could do pound await the the the promise and then then CS all in line. So you don't have to have a loading state if you don't want. You can just do await the thing, then whatever the result is all in one template tag.

And you can even destructure in that. So we, for instance, would have, like, await our GraphQL API's data, then Brackets latest series or something, the data, whatever the variable name is that's coming back from the GraphQL API. And that's basically a one liner to a way to promise And then destructure the variable that I want, and then you can use that.

Another,

interesting thing about me. I have a question about these, synchronous ones. So the await, Does that just stops that block from rendering or waits for that block. Right? Like, if you have if you've got code underneath it, that will still render out, or does that Stop everything beneath it. Oh, that's a great question. I would assume just that block

Because it's the similar to, like, React Suspense where you have a suspended component that's waiting. The rest of the components still render. Like, it It would I don't think it would render like the header, and then you wait for the user component. And then when that's done, then then then the footer renders. I I highly doubt that. Yeah. I don't know. To be honest, we don't use it in any sort of, like, critical infrastructure. It's, like, always something that's, like, a client side rendered only thing that we're we're using it on. So I've never been in a situation where this is, like, the thing I'm I'm waiting on, but I'd be interested to figure that out as well.

Yeah. That's an interesting question. I'm gonna try it,

right after this podcast.

Yeah. And, we'll tweet out the answer once this airs. Now another another interesting thing that you could Described as conditional rendering is a key block in Svelte where a pound key value is something that you can use to swap out data. In fact, we use this on the tutorial page. Whenever you change a tutorial, we're changing the value of the Key, which is the idea of the tutorial, and that updates the content inside of it. So a key block destroys and recreates their contents when the value of the Key changes when the key expression changes. So if the key is changing there and you have some of the things and you want to maybe even do, like, a transition between them, you can throw up it. A transition colon fade on that thing or anything, and it will, conditionally change that block out of that key changes. So that's really nice. Next one I have here is input binding.

This is one huge, huge thing that I like about literally Every other this is Angular, Vue, Svelte, is that if you have a variable, then you will bind that To an input, in most frameworks, you simply just have some sort of bind syntax. So in Svelte, you simply just type bind colon value on an input as an attribute of your HTML input, and it will Immediately bind that to it. And as you type into the input box, it'll immediately do that. And I don't wanna keep ragging on React because I literally love React, and, yeah, I use it I use it for all my everything that I do. But this is way nicer than the React world where you have to create state, it. Create an updater function, handle the key up value, intercept that key up value, get the value of what that event would have been, set that state, and then it would put it in there. It was just like I know and I know you can like, Scott even has a, a React library for making this easier. But, like, this is, like, this is what we do as developers. We make boxes with text in it, and we update that text.

And That is such a core thing of applications that it being so silly hard

in in React world is is so silly to me. It's so silly. And you one of the reasons why it's silly to me is I remember, going to a job interview for a Backbone site.

And this was a bit when Backbone and and, you know, Angular one before React even existed, really. And they would say they they were they had a an interview question for me, and it was like, alright. Can you do some whiteboard coding here and show us how You would update, do some two way data binding in, and they knew I didn't use backbone.

So they were asking me all the questions in Angular just to get my general proficiency. They're like, so in Angular, can you show us how you would do two way data binding? And I was like, I really can't because it just does it for you. And they were just like, wait. What? They're like, yeah. It does it for you. You don't have to worry about two way data binding.

And, it's so funny because That was a very long time ago, and then the amount of work that you have to do to get data binding in React just brings me back to the backbone days of things where you have The amount of stuff you had to do to do it yourself. So I think data binding greatly impacts your your life in in many different ways, especially when working with forms. But it is really nice to be able to create even, like, an object or a writable store and pass it into the form and bind to that entire object The entire form and not have to worry about it. You just have access to it? Like, yeah. Give me that all day. Yeah. It it does like a really good job at,

Doing common things like number inputs and, checkboxes for numbers and booleans instead of you having to parse it and it. And coerce it into the the actual value. And and also you can use the same bind syntax for, event listeners, things on media elements and audio and video, all that kind of stuff. And it's funny. I'm I'm rewriting my entire, video player right now for my courses, and I just, like, was sitting there and being like,

Should should I do this as well? Boom. Like Dude, I I have a video player installed. We could always work on it together, Wes. Oh, so you just send it over.

I I was like, I already have 80% of the code. I just need to like, the the hardest part, which is the The video Vimeo embeds and all the custom controls. Video players are no fun. They're no fun. There's so many edge cases in in video players. And, also, the hardest part of, like, making a video player is the freaking, aspect ratio. Like, you never know how people are gonna be watching it. So you have to, like, it. Skinny and tall screens, wide and short screens, and people who want widescreen, but people who want a smaller widescreen, but the a list of videos beside it. You gotta think of every single possible layout for that type of thing. Not only that, but it's like

autoplay. The the browser's all implemented these it. Crazy autoplay rules behind the scenes now. So if you ever have any issues with autoplay on a site, it'd be be it's because each website has like an or each browser has like an autoplay score for the user that's like behind the scenes that determines whether or not The content is, safe to autoplay for you. It's so weird and impossible to debug sometimes. Some people would just say, hey. I'm having a lot of issues with autoplay, and it sucks that you can't just be like, hey, man. It's all good. It it's just the browser's behind the seen score about your autoplay scores on the same thing. Yeah. That's another good example of, like, marketers ruining it for the rest of us. Seriously.

Because, like, I have to do that as well. And it, like, throws an error when you try to play a video when you're not allowed to. So, like, I just, like, eat the error when when that happens and you have to wait for the user to actually click click the error, and I have, like, just a catch that I just catch it and Throw it into the abyss because I know that's exactly what we'll be at. Toss.

Just catch toss. Yeah. Right into the bin.

Alright. Last thing we have here is child elements.

So it has this concept called Slots, which I really, really like. So when you have a component, you can put slots inside that component. And then when you use that component, you can Just by default, whatever's inside of the component open and close tag will be in the default slot. And then you can also name the slots themselves.

So you can say, alright, this is going to be the sidebar slot. This is going to be the,

main content slot. This will be the footer slot. And they'll just go where you want them to go, and it's a really nice API. It's yeah. It's nice. And you can also use the Svelte call itself if you want, like, Recursive slots, which is cool. A neat feature if you have data structures that are, they make sense to be recursively output like a folder structure, Something you don't know how many folders are gonna be inside of a folder structure. We use it Oh, yeah. For our our inputs and Svelte's toy. We use that. It's a neat feature. Not something you'll use super often, but it's neat.

But, yeah, child components, via via slots. I like it a lot. I know some it's funny because some people Just felt like the child component thing was it maybe a better API, but I like slots because it kind of feels like it's a thing. You're saying here's the slot. It. It's not just some indeterminate children. It's like, this is a component, and it's the component that will be placed in here. To me, it feels explicit, but I I can understand that, like, API as well. You can still pass down a component via props if you want to. Right? Oh, actually, I have no idea because I've never done that. So I don't wanna say yes. Yeah.

There's so many, like, advanced patterns in React that I just have not needed in Svelte Yeah. Because there's, like, a better API for. Beautiful. Alright. Well,

that is how to do things in Svelte.

I thought that would be a good one just because I've been playing with it here and there, and I've had questions for Scott on chat all over, but I thought we'd we'd record something and and chitchat about it. It's really good. Let us know how what you're thinking. Oh, last thing we should say is Vercel hired Rich Harris to work on Svelte full time, which is amazing.

Vercel are the folks behind Next. Js, and, I think that makes a lot of sense because they don't they don't care what you're using. They just want you to host it with them. Right? So now they are putting money into probably 2 of the biggest

web application frameworks out there, which is so cool to see. It's so cool to see. And I'm I can't I'm very excited. I I absolutely very excited, to see what the the future holds there for us. So cool.

Well, I think that's it. On Wednesday, we're gonna be hitting you with a really cool guest. It. And, well, we'll just tease a little bit a little bit more browser coding stuff.

So, we will catch you then on Wednesday.

A Face. Peace. Head on over to syntax.fm

for a full archive of all of our shows, And don't forget to subscribe in your podcast player or drop a review if you like this show.