useWat

[Music] this talk is called use what it is. Friday, it is the last talk. Let's get this over with. I'm going to show you some really weird parts of React. And we're going to make a counter example. I love how they call it a counter example, because it's like an anti- example. Yet every state management library loves to use counters as an example. As if that's the hardest thing to do in state, which it's not all right. So let's start. We have two buttons, we're setting count, we're using state, right? It's zero. You increment the counts, you know, by setting count to count plus one, you decrement it by setting the counts to count minus one. Simple enough, right? Well, let's make this a little bit more real world. What if we want to limit and say we don't want the count to be higher than 10, and we don't want the count to be less than zero?

Easy enough, add an if statement, right? But some bad things can happen. We could actually have many ways of setting that number, we could use a buttons, or we could use the input type number, and I'm ignoring the fact that you could just use input type number and not do any JavaScript, and there's your counter. But, you know, there you go. So, instead we're putting it in functions, all right, so now we think, why do we have two separate functions for this? Let's just put it inside one change count function. And I didn't highlight any other code, so that's all you get to see, all right. But there's another problem we're still using states, so we could easily work around this. And a developer could go in and say, hey, I could change that account to whatever I want just by setting counts. There is no protection against that. So we grow up a bit, we become adults, and we useReducer, so useReducer now allows us to say, hey.

The only thing you could do here is send events, and so when you send events. Now, it is pretty much impossible for us to go beyond 10 or lower than zero, because all that logic is contained inside the reducer. All right, but now let's say that we actually need to share that count value, you see how? Much more complex this is getting. So we are sharing that count value and we're providing it in a provider and then we're using it in our component using the used context hook. But we need a way to update states too. So, what we do is, I actually forgot what we do, but, we useReducer and then we pass in both count and send. So now we have a way to read counts from anywhere in our application and also update counts from anywhere, too. But we have a slight problem here, and that's that whenever the count updates, every single component is going to update with that count.

So now we have to be clever and figure out a way to make the components ignore the count if they don't really care about it.

Play from 0:00

So Mark Erikson sort of talked about this earlier on. And, uh. Instead, we're going to create a special object with send and subscribe, and we are also going to make a hook that lets us select the value and subscribe to it. And, yeah, this is basically how you over engineer a counter example and reinvent Redux, you know? By the way, thanks Mark Ericson for carrying Redux on your back for all of these years, it is really an underrated library. So, yeah, and also thanks Mark for basically giving half my talk. This is going to, you know, be a breeze. So let's talk a little bit about React, right? This talk is called use watt. How many of you know what, like watt is? Watt is basically an expression where you're like, why the heck did this happen this way? But in this talk, I'm going to use this as sort of an acronym.

We're going to talk about the weird parts, the awesome parts and some tricks about React and React hooks specifically. I don't want you to really take most of this talk seriously, it's just, you know, we're woring what's fun with React? In fact, I think that React is a really awesome library framework, something what is React? Well, if you look at the website, it says, React is a library for web and native user interfaces. So there's your answer, right? And so that must mean that things like Remix and next are Frameworks, but we don't really call. Them Frameworks, we call them meta Frameworks, so this gets a little bit confusing. And so that means that if next is a Meta framework by Versel, is React, a Versel framework by Meta, you know? So, React is a library that acts as a framework that thinks it's a library. But if you reference pretty much any tutorial, you're going to basically refer to React as a framework.

It gets really, really confusing. But also, React is not just JavaScript. You know, I. I think that they used to advertise that at the very beginning. And then there was JSX and they said, well, you know what, JSX is just a flavor. You could, you could use React. creates component or whatever, or React. elements create elements. I, I completely forgot, because no never uses it. So then there's WeBack, which is pretty much required to use React. And then you have hooks which have their own sort of rules and life cycles and things like that, and then you have what. React is, you know, basically doing right now? And of course, React wants to be its own language, so it's very far from just JavaScript. And also JSX is weird. I think. When React was announced, we all sort of understood it, like, Hey, that's weird, but it's weird in a good way, because it feels very familiar to us.

It's HTML, right? We're comfortable doing that, and it's a little bit more comfortable than using a templating language, except for this, what is wrong with this code? Anyone know? Zero, yeah, zero, super, super weird. It still gets me. It's one of those things that's really hard to debug because you're not going to notice until it's in production. And you see a little zero there and you're like, what's that doing there, you know? So I think that most or not most of us, but how many of you have started learning React when it basically first came out? It's like many, many years ago. Wow, okay, so that's basically half of you, and how many of you are Juniors? You took a boot camp, you need a job, and you know, you just learn, React that way. All right. So that's, you know, a little bit less than half of you.

But we all have different learning paths and it really changes. Our way of dealing with React, I think it, it is actually a good thing that we learn reacts from the whole. Creates components and the class component thing. Because it really informs the story of, like, why React is the way it is. And when you're learning from a boot camp, you just accept that, like, oh yeah, we just use hooks and it's supposed to work like this. And then you go into JavaScript land and you figure out why are things so weird? And sometimes you go the other way around. Can someone tell me what's wrong with this code? What's what's what's wrong with it? No key, yeah, we're missing a key, right? That's pretty much the only thing wrong with it. So basically we're forcing Juniors to learn functionalist programming in order to use React. You can't like, one of the most common things says, how do I do a for loop in React?

Well, you, you sort of can't. You have to learn this functionalist sort of syntax, where basically it's using functions unlearning half of JavaScript and learning TypeScript, which, you know, is pretty much required nowadays. So, now you have to do this weird thing. In order to create an array of 100 things like this I do by muscle memory. And there's, I read an article, there's like six different ways to create an array of 100 elements where they're all incrementing. It's really weird, but yeah, we're still forgetting a key, right? React's going to yell at us, it's going to do this thing. So what's the solution here? Add a key, easy enough. All right, I'm just kidding, don't do this and this. I actually found this from a tweet, so don't blame me for that tip, I found this on the tweet. And this is amazing because this is the first Reacts tip that saw corrected with community notes.

So I, I thought that was pretty amazing anyway. React is an amazing language or not language. Geez, okay, framework library, whatever you want to call it like, just compare it to Angular and view. This is, by the way, version numbers, but you can see that React is pulling way ahead here. Okay, but actually, let me give you a more accurate chart over here. This is the down. Loads chart. And it's showing like the immense popularity of React, and basically my point is it's not really going away. So just to give you an idea, that's React in red, that's view. We had the great View takeover of 2022, like you could see there, the X-axis is Angular. So, yeah, don't take a picture of that. People will get mad at me. And of course, we have the React docks, right? Thankfully, they finally changed it from React.js or /D dos to React.. But I think we all know where the real docs are right.

So is React the best framework? SL library, SL, whatever? Honestly, I don't think React is even the best React library. Like we have million, we have Preact, I actually discovered that this is the wrong logo for Preact, so I'm really sorry about that. And we have SolidJS that really feels like React, but that's not the point, the point is React is the default React. React is a framework that's pretty much here to stay, and it is what all other Frameworks in libraries are going to be compared to. Like, that's why you have new libraries like solid and Spelt and View, where they all take ideas from React, which I think is a really, really awesome thing. All right, so let's talk about some of the weird hook things, let's talk about useEffect. I actually gave a lot of talks about this and I think you pretty much know what's going to happen here. You saw it at the beginning, this cat is totally vibing to, Versel, increasing, valuation.

Because basically, when you do this with you a fetch data, you're you're paying either AWS or Versel. You know, millions of dollars, right? Because you forgot the dependency array, and, to be fair, in the original docs, that was missing. Unless you scrolled way at the bottom and it's like, hey, by the way, there's a dependency array that you could add to control this sort of behavior. But of course, and I think, you know where I'm going with this, you could do this, this, you have the cancellation, you know, you add the dependency array.

Play from 3:00

But this is going to execute twice on Mount in strict mode. I gave lots of talks about this, but there's even. A page now, you might not need an effect, and so there's a lot of great tips in here. Don't calculate state and Effect, don't reset the state and effect. Do effect logic in event handlers and try to move things like fire and forget effects to event handlers, too. Learn the difference between effect and effects with the capital E. It's really weird. React likes doing it, doing this thing where it capitalizes words and say that means something different. So read the docs. I'm dead serious. Stop fetching and useEffects. That's something that all Juniors do, so just don't do that and do initialization outside. Basically the entire component. It really helps, and you syn external store. Honestly, this should be required reading if you're learning, React. So, let's move on, let's, let's talk about use a effect. So, all right, this is, part of my bad advice. Maybe disable strict mode, because only if you need to.

There's going to be times where it's like, Okay. I know it's ideologically right to have strict mode. But to be honest, most of strict mode is for legacy React. And the only part of strict mode, or pretty much the only part, is for that double execution. And, sometimes it's really easy to say, Okay, I can refactor this, I can move it to event handlers or something else. But sometimes it's really hard and you just need to move on, you know, because life is short. And, basically, I think that it would take you a lot less time to fix that very rare issue. That happens because you didn't use Strick mode than to actually fix things while Strick mode is on. And double executing. I even asked ChatGPT why does useEffect execute twice in React strict mode? I've again, I've given the talk like probably a dozen times, and I still don't know chat TBT doesn't know, okay, and actually, this is.

This is a joke. Because I did ask ChatGPT and it told me like, Hey, it's because of concurrent mode and things like that. Which is why I know ChatGPT is outdated because concurrent mode is dead, and we have replaced it with concurrent features. So, yeah, all right, let's, let's talk about other hooks because I have 11 minutes. Left and too many slides, all right, so this one Mark talked about this is something that gets beginners a lot. Your account is not going to be updated. So this is going to be still zero, still zero, still zero by this time. So you're not going to get 42, which is what you get. When you actually use functions in here, that's pretty simple, but here's a weird thing. And Mark Erikson also talked about this. Did you know that you could set state in a conditional way inside of your component?

Play from 11:00

So this is something where it's like, you can do this and it might fix a quick issue, but you shouldn't do this. Because it's best to calculate everything during rendering and maybe change your data model so that you don't have to rely on just setting states, during render. Here's another weird one. And this goes with the whole just JavaScript thing. Let's say that you have a set and you want to set, so you get set and set from use date with a new set. And here's the thing. Sets and maps and things like that are like they're built-in parts of JavaScript. It's like, why not use that? I didn't even start drinking this water. Don't need it, I guess, all right. So how do we do this? The problem is, this is not going to work because we're mutating this data structure. And this is a data structure where you're like, Okay, what's the immutable version? I guess I have to pull an immutable JS.

And you said, from there, really annoying. I found a really weird hack that makes this work just wrap this in an array, and so this honestly works, so you're destructuring it. The syntax looks a little funny, but when you're setting set, you're setting a new instance, like a new reference of an array. And so it's going to tell, React, like, Oh, hey, yeah, I should change that. So if you want a quick, dirty way and probably illegal way to, to use sets, you know, just do that. But the bigger problem that I have with things like, you know, use dates and the things I think is weird is that we interpret useState to mean use eight. And so we just start having. A ton of them. Then we have more and more state. I searched Twitter for UST state hell, and I got just a bunch of really, really, really scary looking things. So stop being afraid of. Used reducer Okay, this is exactly what used reducer is for, and you could even useReducer.

In a way that makes Ed states a lot simpler, where you could combine it into a single object. And, this is a little cool trick that I tweeted about a while ago. And so, basically, you could update partial data with used reducer, and also useReducer can be simpler than useState for a few things, for example. If you want to toggle something between true and false, you could use this simple, trick right here useReducer. Whatever the state is, negate the state, and the state is a Boolean. So we could just trigger between, you know, true and false by doing this a lot simpler than useState. All right, let's see what else. This is something weird that I found with used reducer, where you could actually change the reducer and React will accept that new reducer. And so it gets weird. Like for in this instance, I'm incrementing by one and then I, you know, click the H1 and then it just, you know, changes.

This is something that I feel like you should never do and it should never be allowed in reacts. Because it's very easy to get to an invalid state. And another thing you should never do is put onclick handlers on H1s and Divs because they're not buttons.

Play from 14:00

But I was lazy, so that's what I did. useRef I love this hook because it's it's the hook where if you want to do something and you don't want react to know about it, you just useRef. You could just like, sort of hide it there and be like, Hey, I'm, I'm not going to tell you what I'm about to do with this data. I. I asked a question on Twitter, like, what are the weirdest, you know, most frustrating parts about React? And one of the most mentioned ones or most liked ones is forward. Ref really, really weird, because it's like you can't pass a ref to something without wrapping it in forward. REF because of some legacy reasons, but I realized you could just rename the prop like I, I just put input ref. This works like you don't need to do the whole forward refath mess, and even if you're fine with forward, ref, TypeScript makes it even more of a mess, so just rename it.

All right? So now let's get to used memo again. Mark Ericson talked about this. React is based on this whole idea where it's okay to render everything top down, but it's really not okay. So Reacts gave you a few tools to work with that, like React. Memo, useMemo and useCallback. But there's still a lot of weird foot guns over here, uh. So, for example, if you're trying to useMemo over here, can anyone see something that might be wrong with this? Anything? No, all right. Well, if you're rewriting, or if you're writing the components in a normal way like this. This is going to create a new object instance every single time. So your used memo is going to do absolutely nothing, even though you're passing the same object, the same data in. So you just have to pretty much put in all the options over there to make sure that doesn't change. And so I thought that was pretty weird.

Also, something that I actually ran into is, let's say that you wants to call on change in response to a value changing. The thing is that React is going to yell at you. Because on change is not part of the dependency array, even though you know that on change is never going to change. You know, it might actually accidentally, just, you know, just keep you know, calling that useEffect, because onchange is always changing, even though value is not changing. So you have to put it in a ref or something, or you could just shut up, React and, and do this. So, honestly, I have this in production code. Don't judge me, you know? This is a tip that I actually learned from Kenty Dods, who was sitting somewhere back. Hey Kent, and so I. I actually thought that this was cool because this is something that I at the beginning, when hooks were introduced, I sort of carried over this.

Idea from you know, oh, you should bind your callbacks and everything, and you should not create new function references. Remember when we talked about that, like, we don't any anymore, but, a lot of people still do this, apparently. Where, let's say you have an event handler like OnClick, and, you're like, you know what, I don't want it, I want to be the same reference. So you put it in a used call back and that might that might rely on something, but here's the problem with this. And from what Kent's explained to me, that your used call back. Every time the function rerenders, it's still going to recreate that function instant, so either way, you're not avoiding creating a new function. Like that function might be wasted. It's going to be immediately garbage collected, hopefully, but still you're wasting it, so better, just honestly, if you. If you're questioning whether this is the right way to do things, whether it's fine to inline the function, just inline the function.

And if you want to remember this tip, just ask yourself, can I put an event handler in? ED callback? You can't, so, all right, all right. So now let's go to use context. Another one of my favorite hooks for many reasons. And you could probably see where this is going to use. Context is a pretty simple hook. Until you get to something like this. And you know, I, I, I've seen this in a tweet, I don't remember the tweet, but you know, people say, Oh yeah. There's lots of solutions to this, like React, adapt and Gearbox, and just all these weird names. Or you can make your own provider's provider and give a provider's object to the providers, and you know, that might work. I don't actually have a good tip for this. This is just a reality of React. It sort of looks like your application buckling from top down over its own weight. And actually, when this was actually quote tweeted by a React's core team member, and he said, nothing's really wrong with this.

But if you've ever tried to refactor this, it is an absolute nightmare to refactor. And I believe that's because, even though we like to say that, React components are like Legos, right? Prov. Providers are like Superglue, where it's really not easy to take that component out of that provider mess, even though that component might not rely on 70% of those providers. So that's just something to keep in mind. Let's talk about rules of React hooks. There's one where you can't call hooks conditionally, except in other Frameworks where you know. They were able to figure it out. So what if you did want to call a hook conditionally? I mean, there's tricks to it. You could basically put it in a component, and have that component just be a dummy component. Where you know, if you conditionally render that component, it's somehow okay. But guess what? The use context hook?

You can call this conditionally. Anyone know why? Any guesses? All right, it's a long-winded answer. So, React. Every single hook when it has its own state, it's doing it by Index, right? So every time React goes through the function, it's like, all right, you're the first hook, second hook, third hook. So that it knows where to look for its state. But since used context actually is looking, you know, just in this some context object, it doesn't really need to reference anything, so you could actually safely use context conditionally. React will still yell at you, but it's totally allowed. So, yeah, this really gets me to this point where rules of hooks are really just technical limitations, they're not programming. Best practice is, and so just keep that in mind. It's something that, you know, you have to accept when working with React. Here's another one, resetting state with key. This is something that I believe, like, hey, this is a really awesome thing for a while.

And this is actually straight from the React docs, where we have a form over here, and let's say that we want to reset this form from the outside. So we have this button. Onclick handle. Reset is going to set this version to a version plus one, and then this key is going to be that version again, straight from the React docs. This looks like a Rub Goldberg machine of like, do this and do that. And then this will magically reset, and to be fair, it does work, except for the normal input type reset button. So if. I fake reset from goats to David or David to Goat. Then this thing that's supposed to work because it's just HTML doesn't really work. So I, I. I actually looked at this example and I was like, that's a little weird. So what's the right or not the right way, but a different way to do it.

So I realized that, first of all, I'm using state over here still, but I'm using it just as a default value. I have input type reset, I don't have any keys, and then I'm using normal HTML. To have form equal to some form, and this some form is the ID over here, and so both resets work. So, you know, we're not using keys or anything, but also with forms, honestly, for the most part, you don't even really need a form library. I. I posted this tip a while ago on Twitter. Where you could use form data and then you could get object. from entries that form data. And then you could do whatever you want. So if you don't need to control your components, you could just specify the name on them and then just use the form normally. So, really, this is a use. The platform, you know? Shout out to, Ryan, Florence and Michael Jackson with remix.

Uh. But yeah, use the use the platform whenever it makes sense because it makes things easier sometimes. Um. Also, keep components uncontrolled unless you really, really, really need them to be controlled. Because if you really take a step back and realize what you're doing, you're duplicating state for no good reason. So just think about whether you should keep a controlled or not. All right pop Quiz local state and simple updates what hook is that? useState? Yep, how about global? I just gave you the answer, use context, right?

Play from 17:00

How about local state? And actual logic? useReducer. Okay, cool, we have one more thing which reacts will certainly fill. What's what's the last one? Yeah, sort of. I just put question marks here. Because, React is a little bit weird about that. And that's why, honestly, so many state management solutions have popped up here. To basically fill that gap. But yeah, you're right, useSyncExternalStore. This is like React saying, or just this. Is React being so close to having an actual state management solution? Where, honestly, you wouldn't need Redux, you wouldn't need Zustan? You might still need X8. Because state machines are cool, and that's sort of my thing. But yeah, USync external store pretty simple, you have a store, you have a subscribe function and get snapshot. But React really has this hook for the purpose of being used for existing nonreact code. Which I think is really unfortunate because they actually did give an example here, which is so, so close to.

Just like they could just wrap this up, put a bow on it, make it an official reacts thing, and then you have your Global state management library in React. So I, I would honestly encourage you, like, just look at this. And if you didn't want to use an external state management solution, you know it's. It's really a great way to go. There's a lot of other hooks where I have two and half minutes left so I can't really go through them. There's UD debug used debug value, where it's really used for KY dos workshops. I, I don't know the other purpose use deferred value, which I. I learn what this hook does, and then I forget it half an hour later. Use ID used for accessibility use imperative handle is honestly a really awesome hook. It's like, useRef, but better. So, use insertion effect, usely out effect. I don't know why there are so many effect hooks, but there are, I don't know what used insertion effect does.

Use transition again, that's one of those things where I forget what it's used for. And then two hooks, which I don't know, will ever see the light of day. Hopefully they will use events and then use, just use. So, yeah, really weird hooks. Now we do have to talk about the elephant in the room, except we don't. I'm not going to get to it, which is RSC's right, and honestly, that's a little bit weird on its own. That's a whole other talk, Al together, where we're using strings to basically determine, the fate of where our components live. Whether it's on the server or client, except it's not the server or client, it's really server client boundaries that it's. Defining, really, really confusing, anyway. My main point is React is awesome, and nobody ever got fired for choosing React. People got fired for doing this, though, so don't do this, or else you will get fired.

I'm. I'm so glad to be here at React Rally. I was here in 2017. And React has really allowed me to experiment with things like using state machines and components and really teaching people about it. How many of you have actually you now know what state machines are? Maybe because of me or XState or something. That's a good amount of hands that's good enough for me. I, you know, introduced Ryan Florence and the state machine at that talk, and so I thought that was really special. And also I took that and basically built a company called Stat. and this is a, a state machine editor that was built on React and on Triangle company. And so these two things have enabled us to move fast. And sure, there were so many weird parts, so many things that we had to get used to fighting with. Performance like React wants to render everything by default, and for highly interactive, canvas-based applications like this, React may not be the best choice.

But it is still a really, really great choice because you could go back and fix those performance problems. Later. I also Al introduced this, this visualizer, and this was about 3 years ago. I want to say this was actually built with upside down triangle, so, but here's the thing I. I actually built this in React first. And then I took it and I, put it in a state machine, and so most of the logic lived in that state machine. And so I moved it to view. And it took me all of 10 minutes to just hook that up, and so that's when I realized that losing all hooks was freedom. And so the main point here is that I have a few spicy takes before we go. If it's not directly related to UI, it should not be in React, so that sounds like sort of a weird thing, it's like, doesn't React.

Want to own everything? And I really believe that hooks are how the UI world communicates with the logic world and. If you look at it that way, things just become a lot simpler. And so, in the same vein, don't lift state up, lift date out again. React has a huge missing part there, where I really wish that.

Play from 26:00

They would standardize U.S. SYN external store and have a way to share states between components without having to use context and render everything top down. Because you do run into problems if you have two components that need to share state, you lift it up to the parents. But guess what, if you have a child component, then, you don't really want that to, care about that state. So you move the components that care under a component, and then you move the components that doesn't care adjacent to it, uh. But then if you have another component that does care about that state, you see how things just get a little bit messy. So moving to use, or, I was about to say, using external store. But just some Global state management, it does make things easier, and that's why so many people have adopted, just external state management libraries. And also don't worry about the Cutting edge stuff. Because honestly, it's probably 5 years away anyway.

Which is great because, it takes me 5 years to finish my side projects, so, you know, that's great timing for me. And also, don't worry about silly things. You remember this, right? Remember when we had a whole Twitter Fiasco about it, or Reddit or whatever we were doing back then? But now nobody cares about this anymore, right? So, in short, and in closing, have fun, make things users want and realize that the what is part of the fun. Thank you.

Play from 31:00