React Hooks - 1 Year Later

1 year later look for you at React Hooks. So can you believe it's already been a year, Scott, that Hooks have been out? Time just flies by.

My, my daughter's not even a year old yet,

so hooks are older than my daughter. I feel like that's crazy. Daughter was not even not even born into a world without hooks. Yeah. That's wild. Very wild.

Yeah. So, yeah, that's true. Neither neither was my son.

He'll never know a world without hooks.

For the best. It's for the best. Yeah. So today, what we're gonna try to do is just kinda go through hooks again. We did a show on them when they first came out, but now Scott and I have some some serious time using hooks under our belt, so we'll we'll sort of go through them and talk about both what they do as well as, like, our thoughts on them 1 year later and and and whatnot. So buckle up for that. Today, we are sponsored by Sanity, which is a structured content CMS, and Sentry, which is gonna do all of your error and exception tracking.

Yeah. So shout out to them.

So let's let's get right into it. You wanna start it off there, Scott? Sure.

I thought this would be, I thought this would be a nice way to kick it off JS how do we feel about Scott of what React Hooks have been replacing in in functionality wise, what they've largely replaced in our code base has been, render props for me, at least. Most of the things that I used render props for, I now do React Hook so much so that I don't know if I have too many render props left in my application at all. So I wanted to ask you, Wes, if this was a a basketball game and React Hooks were were playing render props, who would be winning that game in terms of overall general satisfaction in your mind? Yeah. Definitely,

React Hooks have replaced, I would say I'm tempted to say all, but I did run into a situation a couple months ago where I I needed to, like, lazy evaluate something, and I needed to still use a render prop in that in that case. I forget exactly what it was, but almost everything. I just redid my entire advanced React course. It's not out yet. I'm just waiting for a library to be released, but I've redid all of the code, and it's it's bananas.

How much

less code I had to write and how much more easy it is to to actually view things, and it's all Scott all nested in each other. So big fan. Big fan. Yeah. From a readability standpoint, for me, it's 100 to 0. I mean, React Hooks just make your code so much more readable compared to render props. So if you're sitting on that edge 1 year later and you're saying, well, I don't know how I if I wanna write some of my code this way, I don't know. My code base has never been more readable since I've moved from render props to React Hooks, especially with things like Apollo, the data fetching. It just that sort of stuff to me is you just had nest within the nest or nest in here, and next thing you know, you're indented, like, 8 layers deep when you don't need to be. So I'm always of the, the mind to make things as simple as possible. And to me, React Hooks just make things more simple to read overall. So I'm a huge, huge fan of the visual aesthetic within my code base, but also the readability, the usability, all those things. And we'll get into a lot in this episode.

So let's get started talking about hook number numero uno here, which is use state. Now use state is basically, in my mind, the very first hook that almost everybody picks up because it replaces some functionality that is core to using React that is state. Right? We're so used to using state in our components, and here is the new defact way, essentially, to use state, and that is via use state.

And so this hook, well, you, basically, you define a couple of variables. They come out in an array. So they're re returned as the first two, items from this function.

Now this is made possible by the ability to return more than 1 thing from an array.

Yeah. It returns an array, and it takes advantage of what the e s six destructuring Wes you can name the 1st item something and the 2nd item something. And the reason they use an array there is because if it was an object, you'd have to destructure it based on its property name. But because it's an array, you just

And I how do you name your updaters? I always say set and then whatever the name of this piece of state was. Every time. Yeah. Every single time I have it be set and then the, you know, the the variable name. Scott, typically, I I know this is going to upset david k piano, but I use things like is toggled and then set is toggled.

That's typically how I have my my variables named.

Yeah. Yeah. Makes sense. And then use state also takes a initializer. So, like, if you want to initialize empty state, you can just pass nothing. But if you wanna pass, like, an object with default values, an empty object, often I'll do because I know the shape of my state will be an object. It just doesn't have any properties, or you can give it an object with, undefined properties if you want them to be on there. It could be a number. The only sort of gotcha versus null is a good one. Yep.

The only gotcha you have with USate is that you have to update it all at once. So if your state is an object, previously, you just be able to update 1 property on the object, and the rest of the state would remain unchanged.

Now you need to fold in the existing state over top of of what you have. And if that's the case, then you just and spread it in with the 3 dots in the name of the existing state. Yeah. And that's largely because you're supposed to be looking at this as less of, like, here's the application

Scott, and here is, like, this one particular thing's state. So, like, think about it this way. Instead of having this whole component state inside of a set state, you have individual setters and getters for the individual state items within that component. So a lot of times, people will look at hooks, and they'll say, okay. I'm gonna create my my use state, and I'm gonna try to put all the state for the 1 component on that 1 hook. Now I use many times several use state hooks in 1 component all the time, and that's largely,

how they're intended to be used. Yeah. That's I was just gonna ask that. Like, what's your how do you decide whether you should have multiple pieces of state inside of a component, and how do you decide if you should just have an object? And for me, if the pieces of state are clearly defined before I build the component, then I'll use multiple use state hooks. So you got an example there? Well so okay. So,

I I like to think about it JS how just how connected they are. If if it's all of the information in the state variable is connected, then then it makes sense to put it together. But even if it's somewhat relationally connected but not used in a connected manner, for instance, we have, like, a filter in our sales thing where we have our our charts. Right? Let's say you're setting the year and you're setting the month.

Now I have 2 separate state. I don't have one one state object that contains the the year and the month inside of that object. I would have 2 separate use states, 1 for the year, one for the month. If I'm updating the month, we're just simply changing the month, and that's passing it in. And to me, it's because those things aren't always changed at the same time.

And, largely, if you're changing the month, you wanna keep the year in the same place. Not that you can't do that with any sort of an object thing. To me, in my mind, it just makes more sense that these are separate values being treated separately, and they're being updated separately, so I shouldn't store them together.

Obviously, you can do more, with that. You know, it's all about I think this is maybe like a fine line. I almost always go on the edge of having separate functions. But then if I Node that I'm calling all of our set functions Node after the next every single time. Yeah. And they're probably connected and related in a way that you should be having them all in Node spot. Besides if it gets that intricate anyways or if I'm having to deal with that kind of data, I'm always reaching for use reducer instead.

So if it JS 1 value changed, I'm pretty much always just using use state. And if it's multiple values and more complex data, I'm reaching for use reducer instead.

Yeah. And the if I were to use an object, it would be if the keys of the object are unknown.

Let's say you were counting the number of vowels in in a sentence. Right? Like, you don't want to, like, go ahead and make IOU immediately Wes you could just kind of just add those as you you come into them. And that's the case where I would probably use an object or an array or something like that, to to put them into that state.

Word.

So along the same lines is user reducer, which user reducer is kinda fun because it took a lot of the ideas that, you know, we learned in React from Redux.

And we had this idea of, okay, you're always returning a new object, and you're, being modified in this object by typically, than it is, like, use or set state was.

So, typically, what you're doing is you are defining a reducer.

You know, it it's so funny these names exist. Right? And we talk about them. But to me, these names really kinda get in the way sometimes because, you know, some people will hear the word reducer, and if they've never heard it before, it might scare them off. But, really, all a user reducer is is, basically, it's it's something that takes the previous state and the the action that you want to happen, AKA, like, toggle. Right? You're gonna say toggle.

And then from that, you just return an entirely new object full of the new state. And because you have the previous state, you can take the previous state. You can spread it out and modify it, whatever. You can take that, and you're always returning a new object of the new state in your reducer. And, typically, that's done via just a switch statement that's evaluating, like, a string, and a string may say the action Node. Right? Toggled. Yeah. Increment. Decrement. Yes. Yeah. Yeah. Totally.

I would go as I'm not going this far, but there are several people who have gone as far to say that they use use Reducer for everything. That's Scott I think that's taking it a little bit far. Yeah. Definitely, use Scott is is great, But use reducer, I I think it was a bit of a sleeper hook. I'm gonna go ahead and say it. Like a sleeper hook. In the last couple of months, you start seeing people being like, oh, wow. Use reducer is Why didn't I I think people were kind of Sounds like a wrestling move.

There's the reducer. No. The Sleeper Hook. Gotta get the Sleeper.

Hook.

Node. I think people are were, thinking it was a little bit more reduxy than it actually is. It's simply just a function that returns it. It's no different than a map filter reduce or whatever you're you're using. So definitely check it out. I like to think about it this way.

You had to set state. Right? Set state is sort of the middle of the road. Right? And then you have use state, which goes further into the side of simplicity. You're changing and updating, like, one value. Right? And then use reducer goes in the other direction and says, okay. This is less simple, but more control.

Sanity basically, they they stood on either side of where set state was, one of which is more simple, and one of which is just a little bit easier I mean, more complex.

That's that's fantastic way to look at it. I like that a lot. Yeah. Me too.

Next 1 we have here is use ref. So use ref I actually just learned something the other day. I had no idea about this. So use ref is store JS used for storing reference to something, and I initially had thought, okay. This is only for DOM nodes. Like, you you generally the way that it works is that if you have a a DOM node and you need to access the raw DOM node for for whatever reason, maybe you're using an external library that needs the DOM node or maybe you're using some, like, resize observer or or one of these APIs that's not specifically Reacted, it's just DOM node, then you generally stick a ref on that and and then pass that into, like, another hook that can then reference that DOM Node on the page. So that's the way you do it in React versus doing, like, a query selector, document, a query selector to get that element. Mhmm. And that's what I thought it was for all the time. And I was just kinda, I was working on some resize observer stuff the other day, and I was like, I need a way just to, like, store some data temporarily.

And I was looking at some examples, and they were using use. And, so I sent a message to you on on Slack. I was like, man, did you know this? So I just said, of course. Yeah.

Of course. Scott knows everything. Yeah.

Let me find out what it is.

Here we go. Use ref hook isn't just for DOM elements. The ref is a generic container whose current property is mutable Mhmm. And can hold any value similar to an instance property on a class. So, basically, if you ever wanna, like, just have a variable of some sort of data and you wanna be able to just set that data as just as a normal variable you would, then a use ref can can be used to to hold that. So I was using it for, like, the number of times that something had run.

And now the questions are JS, like, why would you use that versus state? And the reason is that, set state or use state will trigger or rerender.

And then the other question is, like, what's the difference between that and just using a regular variable, like a let variable?

It, probably just, yeah. It's actually a good question because I almost always just use a let or something outside.

Yeah. I I I didn't know the answer to that. I just looked it up. It says use raffle assign a reference for each component while a variable is defined, while a variable defined outside a function will only be called once. So if you have a hook that is running on multiple running on multiple components, then a ref is better for that. I was seeing that too. It's like, why not just use a variable? Because the situation I was using it and it was just a single component. But if you do wanna pnpm it. It's funny because I don't find myself using that that often.

No. I me neither. Needing that technique that often. Yeah. Almost find myself needing to find a like, a constant outside of the

the function more often anyways. Yeah. I was surprised. It's like we're 1 year in, and I just ran across it 2 days ago. Right? I think a lot of the you use use a fact and you state, like, every day. And then there's all these sort of, like, edge case sleeper functions that, I don't even no. A sleeper function is something that, like Waits. Is actually, like is yeah. ESLint waits around you. Oh, this is actually amazing. Yeah. Use ref is just kinda like, neat.

Yeah. I might I might need that. I might not. Yeah. That's that's good. Yeah. That's good. We'll look at it.

So next up is going to be use context, and use context to me is my favorite hook. We we had our favorite hooks. This is my favorite hook. I love you. Use context. I use context all over the place, and, really, what I have is my whole darn system setup. And I'll talk a little bit about this more later on in the this episode when we talk about custom hooks. But I have this whole setup now where I I just did a video on a code blog for Vercel of tutorial showing how we do this. But let's say I wanna fire off an alert. All I have to do is bring in a hook called use alert. And inside of it, use alert is, the set them send alerts, send error functions that I can then use and just call pass in a string and have the fire off an alert that the user then sees come in as a Toast message on the top of the screen. And it's fun because that's all made possible through use context, Node just to a custom hook wrapper on it. But the amount of simplicity that use context has given me in terms of, modifying and using my global state for my application has just been unrivaled. It's been absolutely fantastic.

I really love it. In fact, one of the things I do with this more so than anything is the application state that you could think of as the things you want to use and modify throughout the application, opening and closing the shopping cart, the navigation, the login menu. Those kind of things are all going to be in my global state rather than my data, which is all gonna be in Apollo's cache itself.

Yeah. That's exactly what, I I redid my, it's exactly what you said, shopping cart, whether the shopping cart is open or closed in my advanced React course, as well as a couple other pieces. And I moved it from Apollo's local state implementation, which was annoying because you had to write GraphQL queries to pull it out of there. It was annoying. It was nice, but it was annoying. Yeah. Yeah. I just like, I'm like, I don't feel like writing a GraphQL query to get a boot. Like, I was it's literally a Boolean. Is the cart open or closed? And another function that would set it to be open or closed or toggle depending on on what you want. So, like, what, 2 functions and a Boolean. And I was like, oh, man. Like, this is, like, 80 lines of code to do. Scott 80, but it was too much. This JS like a good web series. Two functions and a Boolean. You could have, like, a 3 3 host show.

That's great. Between 2 functions and a Boolean. Yep. Scott Tolinski.

Anyways, big fan of it. It makes being able to access that global state really, really simple.

You can stick state and updaters in your context, which is it was which is what Scott was saying.

Node question I have is for you. How do you decide whether to use multiple

use contexts, or how do you decide to just stick it multiple things in 1? Kinda similar to the the state discussion we had. You know what I did? That was it's funny because that was going to be my answer. This is kinda similar to the state discussion because the answer is really the same thing for me. It's like, how related are these? Let me just look at my different I have several different contexts within level of tutorials. I have 1, 2, 3, 4, 5, 6. No.

Yes. 6. Okay. So I have 6 different state contexts.

So I have one for alerts. Right? They're their own thing. I have one for anything related to the checkout experience.

So it's not just whether or not the checkout's open. It's whether or not what you have in the cart, what the coupon value is, whether or not the checkout is open, how to open the the checkout, how to close the checkout.

So there's those are all one thing. Right? And so even though there Yarn several different use states, use reducers inside of this one context, they're all very related. My loading state, I have Node for global loading. Now the global loading one is interesting because all it does JS, like, a full screen loading takeover.

I have one for my login.

Is login open? I have Node for our search. So search is a really interesting thing for us. And, again, it's just, is that search open? Is it closed? What's the value of the search? What's the value of the filter? Like, those kind of things all just exist within their own context because they're all very tightly related, and I like to keep those all in the same location.

That really keeps me sane. And another service that keeps me sane is Sanity.

So with more about Sanity, at Sanity. Io JS Wes Morales.

Yes. We've had Sanity sponsor tons. You know by now that it is a structured content CMS. It's a headless CMS to whatever app or website that you're building, and they've been going bananas with the the features. And they recently released what's called custom workflows, which I thought was was really interesting. So, you have a piece of content in your Sanity CMS. And, generally, the the way Sanity works is that you'll have your clients using Sanity Studio, which is like the the interface to managing your data. And they just, released this thing called custom workflows, which allows you to have control over what happens when somebody clicks publish. Right? Like, normally, on a on a CMS, you just click publish, and that data is live.

But with custom workflows, you can do things like notify in Slack that something needs to be reviewed. You could put it in a review in, like, a review queue, so somebody who needs access to that can go ahead and review it. So, basically, you have control over what happens when the piece of data is published or I'm just saying published here because it might not go out to your website before the right people have access to it. So you have, access to custom badges inside of Sanity Studio with this. You get custom document actions, so you can just write your own JavaScript that says when this thing is published, go ahead and hook into that and notify the right people, send off data to the the right people, keep going ahead. Actually, they're using Studio React Hooks Yeah. Which is really cool because, that's the cool thing about Sanity Studios. It's built in React, and you can customize the UI with your own React components. So there's just a hook for that, which is pretty nifty. So check it out at Sanity/ syntax. Do a quick Google for Sanity custom workflows if you wanna see some more examples of of what they've got going on there. You're gonna get double the free usage tier if you go to xanity.ioforward/ syntax. Thanks so much to Sanity for sponsoring.

Cool.

Yeah. Thank you, Sanity.

So let's get into one of the I I don't know. This one is maybe one of the more mysterious hooks even though it's, like, one of the most common ones. In my mind, this is by the way, we're referring to useEffect.

In my mind, useEffect is the most difficult one for people to really wrap their head around and get used to in terms of a, general usage category because it's taking some functionally that we were so used to with our life cycle hooks, and it's flipping it on its head in kind of a substantial way that takes a little bit of a a mental shift in how you think of it. And for a long time, it was always, for me, a translation back to the different life cycle hooks and thinking about life cycle. But at the end of the day, you're not thinking about life cycle. You're thinking about variables, dependencies, and those kind of things. So, okay, what is use effect? Well, use effect is basically a, a function that is run on a certain set of parameters, so to say. Like, this thing is run when you tell it to under very certain specific set of rules. Now those rules are defined as dependencies, and those rules are really just whether or not this value has changed or not. So you you have a function, essentially, inside of your useEffect that is run whenever these things inside of an array have changed. If that array is empty, it's only going to run on amount. Right? So you have an array of something. Let's say you have an ID inside of that array. If that ID changes, then that useEffect is going to run.

Yeah. You get access to all the all the life cycle methods they used to have. So Wes it'll run when it mounts. Yep. It will run when it updates.

And the kind of cool thing about useEffect is the 2nd argument of useEffect is an array of things to watch. So you can pass it some several pieces of state, another function. And whenever those things change, then the useEffect will know to run again. So it's not like useEffect will will run every single time that some data inside that hook updates. It will only run when its dependencies, the array of things that you pass it change.

And then the third thing is that from your useEffect hook, you can return another function, and that function will be run by React whenever that component is unmounted from the page. So if you ever need to do any sort of cleanup, unfortunately, that one is often just looked over, and that's generally where you run into memory issues in React. Because if you like adding event listeners or listening to database or subscribing to real time or anything that happens in in in that, effect, then you also need to unlisten for those things when you clean up. Otherwise, you're just attaching more and more event listeners, and that's gonna lead to memory leaks or, like, weird issues with things running more than once. And you're just being like, what's going on? Every time I click this button, it runs Mhmm. 2 more times than the last

time.

Yeah. Yeah. Totally. And and I think that is, like, such a a mental hurdle for people to get to get over, which is just that we're taking the functionality that existed within however many things before. Right? When you looked at life cycle hooks, it was, like, 5 or 6 or I don't even know how many life cycle hooks existed off the top of my head. At one point, there was a whole lot, like 8 or 9, I feel like. But we're taking all of the functionality that you typically had to duplicate and use within there, and we're we're boiling it down into one sort of superhero function that allows you to do so much more. And the the biggest plus out of all of that is the amount of deduplication within your code that you get from this because you have this one thing that has the job of all these several different things, mount, update, you know, all these different things that existed before within life cycle hooks, you now don't need to have an on mount and an on update. You can do all of that within 1 function, and that gives you so much more control in Node spot rather than, you know, splitting that same duplicate code up into 2 separate multiple separate spots.

I'm just looking at the code for, Dan Abramov wrote this use interval,

hook Oh, yeah. That's a great blog post. Yeah. Yeah. It was it was awesome.

I'm just looking at it, and he used use ref to save reference to the callback function of the interval. So that's another another interesting use case for using useRef.

Fantastic.

Yeah.

There's also use layout effect. So what's the difference between use effect and use layout effect? I know it's something to do with server side rendering. No. Nothing.

In fact Nothing? Nothing. In fact, use layout effect is actually difficult to use in SSR. I have my own custom. I have one called use ISO layout effect for when I wanna use layout effect within server side rendering.

Use layout effect. It basically

Oh, you know sorry. You know what it was? It was that, there was a trick that if you don't want something to run server side, then just stick it in a use layout effect. Oh, that's fine. Because because it won't run server side. Sorry. Go ahead. Yeah. Because what so, really, what it comes down to is that this waits for the content amount within the DOM, and then it fires.

So giving you the ability let's say you had, like think about this back in the day when we had jQuery plugins, and you'd say, here's a div with an ID on it. Right? Well, let's go ahead and find the element by ID and attach this jQuery plug in into this DOM element. And so that's largely where Scott of that sort of world is where use layout effect comes into play. And for a lot of times, though, the way I'm using use layout effect is more or less when I'm working with a library that exists outside of React and I need to use this library within React, and this library is asking for a DOM context or something like that.

That's typically where or, let's say, I need to modify the DOM element itself outside of React, and that's not something that you wanna do too too much, but there's definitely use cases where use layout effect comes into play. In fact, we use use layout effect specifically in, like, a a scroll freeze.

So, like, if you wanna put a scroll freeze on something.

So we wanna trigger trigger scroll freeze whenever this hook What's a scroll freeze?

Like, it stops the page from scrolling? Like,

oh, what it does is basically just a overflow hidden on the body, which stops the page from scrolling.

So I have a use layout effect custom hook that basically allows us to get the window computed style and all that stuff without having to worry about whether the DOM has been completely mounted or not. So this is saying the DOM is mounted.

Let's go ahead and do this action now.

I'm just reading a a blog post on Kent C. Dodds website. It says it runs synchronously.

And then the other sentence I think is important is is your code runs immediately after the DOM has been updated, but before the browser has had a chance to paint those changes. That makes sense that it's it's for layout based stuff. The user doesn't actually see the updates until after the browser has been repainted.

Makes sense. We we use it in coordination also to do that, like, line SVG Node drawing on our courses page, and we're waiting for, all of those nodes to exist. Then we're measuring their position in the DOM with use layout effect and request animation frame and a bunch of other stuff.

Oh, yeah. Yeah. Makes sense. And so in addition to all of this, we have the ability to I mean, obviously, there we're we're not talking about other hooks just yet because there's a whole bunch of other hooks. But in addition to all of this, we have the ability to wrap up anything within a custom functionality as custom hooks, and that's really led to being able to share or use custom hooks. Right? You can bundle them up. You can share them. You can download them. And a lot of times, you could just copy and paste them from another application.

We have our our huge own folder of our own custom hooks, which I'm gonna talk about in this how do we use them section.

Here's how I like to think about custom hooks. Custom hooks in my mind, whether or not this is, you know, an actual perfect description for them, To me, a custom hook, you could think of it as like a React component with no UI.

You can use the stuff that you use within normal React components, whether or not that's use stay, use or do's, or use context, any of those other hooks, useEffect, refs, whatever. You can use all of that within a custom hook.

But instead of returning UI, it's returning data. So in our case, it's typically going to whether or not it accepts different parameters, it's going to return an object with parameters or it's gonna return a single value or it's gonna return this or that. Either way, it's not returning JSX. It's not returning UI Node. And then you can encapsulate a bunch of functionality, stuff that you do elsewhere, encapsulate it all into Node little bit. So that way you can drop into your components with a simple use this hook. So to me, these custom hooks are the area that I've been the most excited about. I have a whole folder of custom hooks which we'll talk about in a little bit, but just stuff I love to I love to write these, and I I love to find little situations where my code can be swept under the rug a little bit to be,

you know, make my components cleaner. Yeah. I I find that it it forces me to decouple functionality from UI. Mhmm. Whereas with React, I would just stick it in the life cycle methods. And then if you needed to use that functionality somewhere else, then you have to use, like, a higher order component or render prop or something like that. And with these custom hooks, it just forces you to put them in its own maybe in its own file or it's its own thing, and then you can just go ahead and use them. It's very Yarn. Like, that's maybe another thing about React because it's very hard to write something that is not reusable with React hooks because it's it's hard to make it tightly bound to the actual

the component that it's being used in. Yeah. And we're not I mean, we use so to give an example of a custom hook we use, I'll talk more about a lot of them, but here's a very common one would be like a use click on outside Wes, let's say, you have a Node and you wanna say if you click anywhere else other than within this modal to fire some sort of ESLint, And that to us is a perfect example of functionality that you typically write within the component. Okay. Here I have this model. When I click outside this model, I want it to close. But wait. There's a lot of other situations where we could use that, like a the drop down menus or this or that. You know? Well, why don't you just

extrapolate that out into its own thing? You just click on outside. You pass it in a ref, and you say, hey. If you click outside of this ref, fire this event. Boom. Bingo. Bango. It's so easy and so awesome. I absolutely love that. One other thing I've mentioned is probably known to a lot of people, but, like, you can return anything from a hook. So whether that's data, that's most likely what you're gonna be doing. You're gonna be calculating some sort of state internally in your hook, and then you return that data.

And then you can just go ahead and use these live variables anywhere inside of your your application that has or anywhere inside your component, I should say. I guess you you can pass them down to anything, though. You can return state updaters so you can return functions that Yep. Handle it. So whether that is returning the the setter that comes from use Scott directly, I've done that before.

Or whether it's passing returning, like, a custom function that internally will use the the state updaters.

And then another thing you can do is you can return refs from custom hooks. So, there's 2 ways to to Scott. I'm talking about dom Node refs here is you can pass in a ref into your hook, or you can just create the ref inside of your hook and then return it. And then you can set that ref on any

element inside of your component that you like to. Yeah. And and those are all fantastic use cases for these things. Basically, at the end of the day, you're writing your your own custom hook. You know? Even if you just had a function that that all it had inside of it was a use Scott and, set state and the state and return the set state and the state.

Like, that is a custom hug, and that's really, like, the most bare bones example that you can just take it from there and make them more complex.

And and once you really see it from that, the perspective, it's like getting eyes into the matrix. You're seeing through the lines of the code, and all of a sudden you're like, oh, yeah. I can I can make my code so much drier this way? Not only so much drier, but if you're writing these kind of functions and utilities and, custom hooks to reuse throughout your site, what you're also doing is you're reducing the amount of variability throughout your team of writing these functionality.

So you have this functionality that you can share. No longer are you approaching a problem from a way that each person might address it differently. You have one source of truth for this problem. Everybody can contribute to it. Everybody can just use it. And then it's it's really probably going to make your code much easier to Wes, right, because you're not having a whole bunch of different implementations of the same kind of thing. It's just allowing us to share functionality in those kinds of ways.

So I wanted to talk a little bit about how we use hooks personally really quick. I can just go into mine, zoom through it here.

The way I like to use hooks is I have a folder within my UI called hooks.

In that folder, I have each hook has its own, each custom hook, I should say, has its own file, and then I have an index dot ts that basically imports and exports all of them. In addition to this, I use a Babble alias. Are you familiar with Babble aliases?

No. What's what's that? So Babble alias,

I use it as a module resolver within Babble, also within TypeScript. And what that it does is allows me to set an alias to a given directory.

So my Scott forward slash u I forward slash hooks folder, which actually points to the index file, has been essentially renamed as just hooks, and it almost exists as a package within my application. Now some people might not like this from a Clarity's sake because it looks like a node module called hooks or something. But Yeah. You could always assign some sort of a, you know, a a signature to it to indicate that it is a local package or a local alias rather than you know, some people use the at sign,

to do that. Oh, so this is the the babble plug in module resolver Correct. So that you don't have to do the whole song and dance of, like, how many levels deep am I right now, and how many levels do I need to go up in order to get to it. And I use that all the time.

And and so I use that all the time for all sorts of different things. I absolutely love it. And some people who would approach our code base GitHub knowing that, again, it might not be the most crystal clear thing. But once you you once you're used to it, you love it. I absolutely have. So all of my hooks are imported from an index file. So all of my hooks are available application wide for me to be able to just say import this hook from hooks, any hook I want. Uh-huh. In the hooks I have, I have used click on outside, use course path, which draws the Wes path, use dimensions, which pulls the dimensions of an object based on offset scroll border box. I have, use ISO layout effect for server side rendering layout effects. I have use is a store, which just tells us if the URL is a a forward slash store URL. And that, like, allows me to just get a simple Boolean. Right? I can drop that hook anywhere on the page, use a store, and then it just returns, is it a Boolean? Is it the store? True or false? Yeah. Okay. We're on the store. Might seem silly, but

inside of that hook is likely,

like, a use context that pulls the URL down. Is that how it works, or do you just pull the window location? It's just the React Router use location or whatever. Oh, yeah. Yep. Okay. Yeah. Simple. That's great. Simple. In addition, I also have the, 2 2 hooks that people aren't going to like. I have use unmount and use mount, and I'll tell you why I have use unmount and use mount. Those are the simplest one. And people say, hey. I don't want you to think about useEffect as, you know, life cycle hooks. Well, useMount and unmount are so perfect for when you have code that you wanna quickly convert over to React Hooks, and you don't want to have to take time to really reevaluate. You just wanna get into hooks. And then maybe later, once it's working, you can reevaluate it. So I use this largely as helpers more than anything. I have, use referral cookie, which just checks for cookies, if somebody's a referral.

Let's see. I have use scroll freeze, use theme, which grabs the the user's theme property and then sets a class to the body based on whether or not they have a specific theme. That's actually one of the ways we power our theme system on LevelUp tutorials.

We also have some really, some some ones that you see from other place, like use why did you update.

That allows us to get the whole why did you update thing going on. If you don't know why did you update, it's a great way to get some visibility into your React components.

And then, also, you have one called use window width that just returns the window width. So just like I said, little tiny bits of functionality that I just want throughout my application. Sometimes I want the window width. Sometimes I wanna know if it's the store. And then I don't wanna have to do the bring in location, check the location string on every single one. I just wanna have it in Node spot.

Beauty, I think you just converted me on this Bail plug in module resolver. It's so cool. Yeah. Let me let me blow your mind on this one a little bit because here's what I use this for. I use this for several things. I I use it for my UI folder.

Mhmm. So if I wanna pull anything out of a UI, any React component, it's just UI forward slash tutorials, whatever. If I wanna have something in state, I have all of my context as an alias to Scott. So I just bring in my use alert from state. I also have it for, hooks like we mentioned before, and I also have it for elements. If I have my styled components elements, bring in card from elements. That's it. Oh my gosh. Love it. Man, for some reason, I always thought you had to do this in webpack.

So I was I was just thought, nope.

Yeah. Wes do it in in TypeScript and in Babel, and Meteor doesn't care it's the same. Just Babble. That's great. Yeah. I'm definitely

gonna take this. It's there is a little bit of weirdness where people might not understand that it's local. Can't beat the cleanliness.

Maybe maybe even, like, could you just start it with, like, a forward slash? Like, just to show? People Scott it with an at an at sign, but you could you could start it with anything if you wanted, I think. At notes to me, that is just the namespace package on npm.

Maybe like a like a Node.

What you can't use. You could pick anything. Yeah. Pick a pick an emoji. You could use emoji. I don't think you can use emojis. I tried. Remember when fragments came out? I tried to alias react fragments to ghost emoji.

That's good. Maybe maybe I could do it now. That'll be good. Cool.

What do I have here? I don't have as nearly as many as you, but, I I've certainly been using them. I wrote some custom used form hooks. I know Formic has hooks and things like that, but so often, I don't necessarily need an entire library for managing my forms Yeah. Because I just need to set some Scott, then then render that state out to the value prop of an input.

So I have, used form where at a form level, you declare your, your input names, and then you can put those values into any of your your child inputs as well as have a handler for updating them JS well as have a handler for submitting that entire form. So I've been been really happy with how hooks and forms work together.

I've done a bunch of stuff with resize observer. So I was working on my own website, and I wrote a hook that would what did I call it? Use grid rower or something like that. And so it's it's similar to resize observer, and there's definitely a hook out there for resize observer. I just wanted to write it myself just so I can get comfortable with how it all works. And I basically wrote this hook that will tell you which row a wrapped flex element or grid element is on because that's something you can't do in in grid is tell what row something is on. And I Node it to style things differently that were on row 2. Yeah. It worked out really well. Big fan of it. Although I did run into some render loops because if you change the size of something when it's on row 2, then it gets small enough to fit back onto row 1, which makes it bigger, which makes it wrap, which puts it on row 2, which makes it smaller, which makes it fit on row 1.

So in that case, I had to write some code that would only let it render twice based on the width. And then I said, if the width has not if the width has not changed, stop. Like, you're you're out of control. And that's where I used the RAF. I was counting the number of of re renders. You're you're cut off. You get a you got to stop. Yeah. I was like, you you're out of control.

You've got your 2 renders. And the reason I did too is because I was running into an issue where it would render once and not wrap perfectly.

So I was like, alright, after 2 renders, this thing is in the right spot.

Stop here.

And then whenever the width of the window change, then I would I would cause that thing to to reset, and it could start to rerender itself, which is pretty cool. I did a little video on my YouTube if you want to check out how that works.

Use wicked Favicon.

If you go to the uses.tech in your website, you notice that the favicon is just streaming letters onto the favicon, and that's all done via Canvas.

So I just basically take each letter of uses and write it to a Canvas and then export from Canvas and stick that into a favicon Bos 64 encoded.

And if you wanna use DOM APIs, that's considered a saw a side effect, and the entire Canvas library is a DOM API.

So I stuck all of that into a, useEffect hook and wrote my own little thing for that, which is pretty fun. So if you wanna check that out, I'll link it up in the show notes. It's silly, but it shows how to use intervals and and whatnot.

Cool.

I I have 1 more that I wanna talk about briefly. I know we're we're running late on time here. But, so I just recently did a a code blog video on this. So if you are interested in learning a little bit more, check out the LevelUp Tutorials YouTube. But I mentioned very briefly that I started writing custom hooks for my context updaters.

And so Mhmm. To me, what this has done is it's taken typically, when you write context with use context, you bring in the context. You import the context, and you say, well, you import use context as well as the context itself. Then you say, use context and wrap that around your context, and you can get the variables out of here. And I I had this, like, tiny little epiphany that JS like, wait. Why can't you just throw them into a custom hook? And then all of a sudden, you don't have to import the individual context into stuff, and you don't need to import used context. You just need to import the 1 single custom hook.

Just stick the context in the custom hook. Right? Correct. So now that too. It's so good. It's so good. So now I just have instead of,

alert context, use context, whatever, I just have 1 single custom hook that is use alert, and use alert spits out, set alert, send alert, whatever. So, just a a minor aside there, one of my new favorite functionalities for custom hooks there.

I did that too, and I think it was a uses Scott tech site. And I remember thinking, like, oh, I have to pull in the context and then pass the context to a hook, And then I go, oh, but you can use hooks in hooks in your own custom hooks. Right? And that was that was a big moment for me too. I'm glad you mentioned that. That's awesome. Yeah. What about hooks that you don't use? Hooks that I don't use. I do not use

like, I don't think I in I don't think there's any use case for me within Vercel up tutorials of use imperative handler.

Or or do you use use imperative

handler for anything, Wes? Yeah. Like, I don't even know what the hooks that I don't use are Right. Because I just haven't run into that situation.

Like, I've read the docs, but That's the whole thing with this stuff. Yeah. No. Node what does use imperative handler do? Use imperative handler customizes the instance value that is exposed to parent components when using ref.

As always, imperative code using refs should be avoided. In most cases, use imperative handle should be used with forward refs.

So I don't know if that clears it up for me. I don't I haven't hit the use case where I need to use that.

It's showing an example of focusing an input.

I don't know.

No. I haven't haven't run into that. And, like, I think the thing is that whenever I run into a situation where I can't solve something, like like, I was talking about that refs example the other day, I was then then you run into it. You go, oh, okay. That that's what that's for. It's it's obviously there for a a use case. There's also use callback and use debug value.

I've never used either of those. What does use debug value do? Use debug value basically makes it more obvious when debugging, like, what the custom hook name is because, like, right now, if you use a custom hook, I think it comes in as Scott, and use debug value displays a custom label within React DevTools.

So I almost never use this because the context of the data itself tells me enough. But if my data is

not contextual enough within my custom Node, And I'm gonna say use debug value to to get a little bit or even just within said state or whatever. I Node it exists, but I never Node it. I don't think. That's cool because I think if you've got, like, a lot of booleans that are just true or false Yeah. Right. And it just says true or false. So, like, what does that even mean? So if you wanna say, like, online or offline or

Yarn open or cart closed instead of true or false, that's what that's for. Totally. I try to use that. That's pretty nifty. It's nifty, but they don't want you to leave it in your Node. So it's just for just for checking things out.

Oh, yeah. I've never left that debug line in my code ever, so that wouldn't be a problem for me. Never ever left any debuggers in my code ever.

So the question here is, are hooks like, a year later, are hooks harder to learn? I'm gonna say

Classes or what? But then classes

and render props and things like that. I definitely think they are harder to learn because you have to sort of understand about closures and memoization.

But I think once you get over that initial, this is how that works, I think it's much better, to go. So I think there's definitely a little bit more of a hurdle, but definitely worth the the hurdle.

Yeah.

I think initially and conceptually, hooks are more difficult, especially with useEffect.

It's much easier to think about life cycle methods, especially coming from most other frameworks and things that have used life cycle type methods for so long. I mean, we've been using life cycle anything for just about, I don't know, forever and ever.

So for me, initially and conceptually, it was a little bit harder to pick up the whole use effect thing, and you're just thinking about the render cycle itself, not life cycles.

And I think that once you once you pick up those those broad concepts, once you pick up the concepts, I think it's much easier to use. It's easier to use in practice once you understand the concepts.

And I think it it gives you less foot guns in my mind because you're no longer having to duplicate code for life cycle methods. You're you're following some very specific patterns.

I think there's less ways that you can get yourself into trouble with hooks, but that's just my own perspective on it. Yeah. I I agree as well. Like and shout out to the React team who even thought of this

concept, right? Not everything. I'm certainly not a good enough JavaScript developer. Like, if you were to, like, tell me, okay, Wes, I'm going to sit down and you think of a better way to handle everything in React, I definitely wouldn't have come up with it. So it's really cool to see, the React team thinking on these concepts for so long, and that's why I'm so excited about suspense as well. When it ever comes out, it will be a game changer because of the amount of time that they've put into thinking about all this.

Yeah. Totally.

Last question here is, are classes going away? It is which is everybody's favorite question. Are classes going away? Am I we're really gonna have to do I have to convert all of my components? The the famous line is, no. You don't have to convert your components. And, no, they they don't expect you to convert all of your components.

I always take the the line of things JS, like, when something comes into alpha, I gotta rewrite all no. I'm just kidding.

I I have to look at this as in

I really like hooks. And if I'm going to take the time to rewrite something, it's going to be for an exercise to learn something. Here, I have a bit of code, a bit of functionality that I understand really well. And by converting that to hooks, I'm not doing it because I want this to be in the new fancy thing. It's because maybe I'm taking a bit of something that I already understand, and I'm finding a way to express that. And hooks teaching me quite a bit about hooks themselves.

So if I'm rewriting code, it's for that reason specifically.

For the most part, I write everything in hooks. I don't even think I have any class components left in my site. I'm sorry, because I did do that. But I think classes are going away. I don't see any need for them. They're overly verbose at this point, the duplication in life cycle, which we talked about a bunch of times.

I just think there's no reason to use them. There are some things you still can't do, within React Hooks, but I don't use any of that stuff. I almost dropped the swear word, but I don't use any of that. So

Yeah. There's get derived state from error, get snapshot before update. Don't use it. The component did catch JS a handy one, the error boundaries.

You don't use it.

That's probably the biggest one that Error boundaries are Node, but yeah. You just don't don't use it. Pnpm error boundaries.

Yeah. How? If I don't write errors, Wes. I don't write any errors. Oh, okay. There you go. The error boundary is my brain. Yeah. It you don't need error, but there's that that meme. Don't need error boundaries if you don't write errors. Well, there's no invalid there's no opportunities for, like, invalid state or for data to come in because I'm using TypeScript and I'm using all of these systems. My API JS all typed. Everything knows whether or not it's going to be defined or not. There's never gonna a situation where a component is erroring out.

And I say never, but, yeah, it's it's not really.

Oh, yeah. TypeScript, man. Let me just talk. Do you have 5 minutes for me to tell you about TypeScript, Wes? Oh my gosh.

Unsubscribe, please.

We have to do that. We have to do the TypeScript Scott, though. I've been I've been using a lot more TypeScript lately, and I I think it would be fun to do a a show on that. I don't like it. I love it. You love it? Big fan.

I would say classes are going away.

I would not rush out and rewrite all of your class based code, especially because some people have, like, many hundreds of thousands of components or maybe just thousands of components.

And that's not a good use of your time to rewrite already well tested components. Right. But I definitely have not written a class new class based component in the last probably Yarn since they've come out. So, big fan. Big fan.

Big, big fan. Cool. So if you wanna write code without bugs just like me, you're gonna wanna go ahead and use a century Sanity century.i0, and you're gonna wanna use coupon code tasty treat, all lower case, all one warp. You're gonna get 2 months for free. Now century is the error and exception handling service that, well, when you write those error boundaries and that error pops up in your code, you might wanna know about it. Right? So maybe you can fire off a message to Sentry with that error and say, hey. This happened.

Here's the source maps. Here's the release. Maybe here's the user that it happened to, this poor soul.

And you can track all of that in Node interface. That is beautiful, by the way. And, Sentry just catalogs and catalogs all that stuff so that you can see it exactly how it happened, what happened, and then you can go ahead and solve that bug. You click that little play button, and then it's gone forever. You you've you solved it, and it's gone because that when you fix bugs, they never come back. That's for sure.

So so you're gonna wanna go ahead and use a service like [email protected] o coupon Node tasty treat, all lower case, all Node word, get 2 months for free. Try it out, throw in your code, throw in your error boundaries, and behold, all of the mistakes that you've made and solve those problems.

So check it out. Thank you so much for Century for sponsoring.

Now as part of the show, we get into our sick picks. The stuff that we pick that is sick, the stuff that we love could be anything, could be could be nothing. I don't know. What do you got, Wes?

I have got some kids' headphones.

We recently updated our I think it was 8 year old iPad. We've had the same, like, 30 pin connector iPad from

well before I even had kids. That, like, giant wide one. Yeah. Yeah. You, like, Sanity even get in the doorway. It's so wide.

And it it was it was hilarious because like, it it's kinda sad because it still worked great. It's just that we kept, like, losing all of our chargers, like, the old 30 pin connectors. And every time we'd find a new one at a thrift store, we'd be like, oh, I got another one got another one. One that has FireWire on it if you want one.

That's amazing.

Yeah. FireWire 400.

The original iPad You bet.

Had a FireWire 2 30 pin connector. That's where it came from. Yeah. Really? Oh, man. I have I have the iPad still. I have the the white one before they when it was all motion based and Really? Touch based rather than click and go. Wish I kept that. I still have I had the 1st iPhone too, and I'd I'd sold it. Mhmm. Kinda wish I had kept on to it. Oh, well. Yeah. And, like, the the battery on our old iPad was just like, it would take, like, a day and a half to charge. And then if you were watching a video while it was plugged in, it would still drain to 0.

So we've got some car trips coming up, and, we bought this pack of headphones for kids that are internally limited, so they don't go too high in the volumes.

And it comes with a splitter and everything.

So it Wes pretty cool. Their MPOW kids headphone, they limit them to 91 dB, which is pretty cool. They look they look really nice, and they stretch like crazy because my kids are so destructive with their their things, and they're ready to put them to the test.

Yeah. Kids, man, they are destructive.

They just everything. Well, what can you find it? And they're gonna like, it was so funny. Like, land that we were, you know, we had a really sunny day yesterday, so we were going outside. I'm gonna we're about to pick up some some dog stuff that was in the yard. McClendon, just stay over here. And he's like, what? Stomp through the yard. I'm just like, oh, come on, man. And he gets poop all over his shoes. It's like, if we can find something, the kids are gonna break it. They're gonna step in it. They're gonna do whatever.

It's just that way it goes, man.

So my sick pick is going to be I'm gonna wanna apologize for a sick pick I had a couple weeks ago, which was that, I don't know, Mick Mick Vercel YouTube channel.

I really, initially, I watched, like, 5 or 6 of those videos, and I really love them. And then the more I got into them, I was like, wait. He's just, like, reading a Wikipedia page, and he's like, there's a very definitive formula, and I I I wanna apologize for that because the host of that show, he I don't know him personally. I found it, like, just so formulaic and definitely kind of annoying and overly dramatic. So I'm very sorry if you watched that and were annoyed by it because I got through, like He just got unpicked.

I unpicked. I got through, like, 5 of them. I was like, this is pretty great. And then I got through 10 of them. I was like, I'm kinda regretting this one.

So I I'm gonna do a follow-up pick, which is a better version of a similar type of thing, and this JS, it's called Warp Stories from Ars Technica. And if you don't know Ars Technica, it's a blog. It's been around forever. And these Yarn, like, you know, 20 minute, 30 minute long explorations from some of the smartest developers on the planet talking about problems that they had in the development of some essential works and then talking about how they overcame those problems. For instance, there's a really good Node, if you ever played the game Myst back in the nineties. This was how Myst almost couldn't run on a CD ROM, And they were talking about not only the history of Myst itself, but how these rendered, rendered designs, they needed to find a way to essentially gain the system on a CD to make it actually work.

And so they are talking about the technology behind how the CE reads data and what were the certain situations they went in. These are just extremely smart people with extremely, really clever solutions.

There was the this Crash Bandicoot episode, and I never played Crash Bandicoot. I'm not I'm not super I mean, I'm familiar ish, but I'm not super familiar.

But he's talking about these these ideas they had that are, like, really brilliant, and he's coming up with them. And he's just like, oh, so well, we've found these limitations with the the libraries that PlayStation gave us, so we just, like, wrote our own or just started hacking away up the PlayStation official libraries that they gave us, and nobody else was doing that because those are the official libraries. People just assume that they were all performative and, like or performant, not performative.

They just assume they're performant. So we just started realizing and looking into them and seeing JS, Wes, these could be more performative if we wrote them entirely. So they just started hacking away like the system libraries.

It JS it's really fascinating and they're really in-depth stories.

And they're all just a single developer talking.

No drama whatsoever. No over the top nonsense. No sound effects. I love this stuff. So, check this YouTube channel out. More specifically, check out this playlist, the war stories. There's 21 videos. Well worth your time.

Awesome. Well, thank you for tuning in. Hopefully, you enjoyed that. We'd love to hear what you think about React 1 year later. Make sure you tweet us at syntax f m or post up on the Reddit, reddit.comforward/rforward/ syntaxfm.

And there's been some memes posted there lately. Some memes? Some memes. Meme. Well, in in Canada, we call them memes.

Meme.

Marmos.

Oh, alright. That's it for today. Thanks for tuning in. Catch you on Monday. Peace.

Peace.

Head on Peace. 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.