The Weird Things About React

So good morning, everyone. Let's get right into it. Let's talk about the weird things about React. And thanks for the broken committee to allow me to alienate you right in the morning and regret your life choices.

But before I do that, briefly about me, I'm Nick Graf. I work on Serenity with a team of three or four. It's encrypted, I'm also a tutor, and depending who is asking, I'm a consultant or freelancer. And let's continue with me.

My journey with React actually started with 0.12, the version, or 0.13, and by that time everything was really, really awesome. JavaScript didn't have classes, so we just had function, create class in React, and it was pretty good. And then 0.14 came along, and then the first thing happened, and I was like, that's a warning sign, what's going on? What, 15 now? Why not 1.0? And they knew they did something odd here, because they released this really long blog post about why they're doing this, how Semware works, but they are doing it a bit differently and whatnot. And so either this is regret, or dedication, or commitment. And for me, I didn't care. I felt like, okay, at least they know it, they're aware, this is good enough for me, and the world moved on. We had 16, 17, 18, and things were good, again.

And what I really like about React is that you have React.js.org, the documentation, but all the nitty-gritty details, all the thinking behind it you can find on the inofficial docs, Twitter.com. It's really great. Follow these three profiles, and you will know about the thinking, about the background, you really want to know if you are using React over a longer time. Let me give you a couple of examples. Did you know you can use the key attribute to basically remount components? So if you look at this, it's like very simple component application. But what you do is, when you click the button, you're actually updating the ID. So for example, if this goes from ABC, a string, to GHI, what happens is you're actually remounting the component. And this is nowhere on the official docs. But once I figured this out, it was fantastic because I know you shouldn't use this all the time, but sometimes it's really, really handy. If you have someone that built a really bad component that is using useEffect completely wrong and you can't fix it. You can just remount the component. Awesome. Very nice trick. And you will not find this on the official docs. Nowhere at all.

So I wrote a blog post about it and telling people, yo, don't use it. But this is like inside information that you can leverage if you really know about it. But then you go to Twitter.com and they actually, Sebastian explains, this is a completely valid use case. And it's like, why is this not anywhere on the official docs? I found this weird. So I proposed like, why are you not adding this to the documentation? But thanks to Dan, he actually said like he will keep it in mind for the rewrite. So I'm still, it's not there on the beta docs, but I'm looking for it, that eventually it will come. Hopefully.

And that brings me to the other things. Who of you has seen the new beta docs? Excellent. Who of you has read through it from the beginning to the end? Well, you really should. They are so excellent. You still can learn something there. Every time there's a new section, like I would go right into it and read it. And I really enjoy it because even like I'm doing React since years and I feel like I'm a consultant. I've seen a lot, you know. But I still learn something there. And it's great. So if you take one thing away from today or at least from this talk, read the docs. It's really, really good.

I promised you more examples. Didn't you know that since 2018 you can actually return a render undefined and return undefined? So this is a valid component. And, okay, that was actually an official blog post, so they mentioned it, but it was like zero mentioning why. And I was like I felt like null was a great decision and I really don't want to bug with people accidentally returning undefined and then you have like weird bugs. And I was like, come on, why is this happening? Why this change now? Why not a year ago? And it has nothing. And you accept on Twitter.com. I mean, it took them some time. I think it was 15 days or so. But then they actually released an explanation on their RFCs and this is the second thing. Who of you knows about the RFCs, this new React RFC thingy? Raise your hand. Wow, not too many. Read this. This is excellent. Sometimes it's delayed, like undefined, it took them a while. Only after people asked a lot of questions. But they really explain like the thinking and you can actually propose an RFC by yourself. Like if you wanna see something changed in React. So the beta talks and RFCs solve this Twitter.com problem. And not the whole Twitter.com problem, but at least the React with the unofficial talk problem. Okay.

Let's move on. Completely different topic. Another weird thing about React. Composition. Composition for me started, again my story. Mixins. If any of you has ever seen Mixins. This was like 0.12 or 13. This was marvelous, you know. You had two-way data binding, because we are all coming from Angular back then. And so you have to have two-way data binding. We had memo long before you ever seen memo. And it was great. We were building a lot of things and mixins were good and we could compose logic.

But then, you know. Another blog post came out. So, mixins considered harmful. So you have two choices, either refactor your codebase or you quit your job and move on. Yeah. People did different things. So, how do we compose now? How do we handle composition? Well, we moved on to higher order components. And I was totally all in. I was like, right away, at that point on this hype train with functional programming and higher order components, it was so beautiful. And you could compose everything and it was completely unmaintainable. It was like, it was terrible. The thing is – I mean, it was good for consulting, you know, a lot of good income, but it was like really shipping something was not a good thing. So we realized, nah, this is a bad idea. Twitter and he joined the React team. And then he made this announcement. Higher order components are a bad idea.

So we got rid of them. Well, almost. So we still have mem on forward ref. I wish forward ref wouldn't exist, but it's another story. And at this point, I was like, I'm a part of an experiment. Like, I'm constantly having to change my code base to get composition right. And yeah, I found this weird. And it didn't stop there. Obviously.

Then we had render props and I really hated them. It's like, I mean, all this nesting above nesting above nesting, this was horrible. And I never spoke out loud. Okay, I have to say that. But like, whoa, render props were the worst thing.

So then we got our savior, hooks. And hooks are great, because they're a concept that is really weird. They're stateful functions to solve our problem with the non-extendable classes that we had before. And all that we can do are templating logic in our business logic code. It's fantastic. But hooks is actually, I'm okay with it. Like hooks are good. They have a clear rule set with, like, they should only be used in a React component, there should be no conditional use. But in the end, you actually go to Twitter again. And you realize you can use context conditionally. It just didn't allow you to use from ESLint. But basically it works and will not cause any problems. You can do it. Still probably not the best idea. But it's all a lie, you know. But in the end, I think hooks is really something that at least I feel comfortable with, and I hope we are almost at the end of this whole composition story, but time will tell.

Let's talk about something completely different again, another weird thing, or we come to the weird thing. I love named exports. They're really great. You know the auto-completion experience in the editor, it's fantastic. And at a point in time, a couple years back, I could agree with all the teams I was working with, we only used named exports. Everyone was on board, it was fantastic. But then this came along, React Lazy, because React Lazy requires you to have a default export for your component. I was like, no. All our decisions flushed down the toilet and we have to rethink again. And I think with all the teams who went back to having default exports for components, we were not happy, but okay, we accept it. I mean, well, we accepted it. At this point, you also feel like maybe the grass must be greener on the other side. So for example, we looked into Angular, and we found like, okay, what's the current version of Angular? So you have like one, two, three, no, three, one, two, four. And you're like, okay, forget it. Back to React, let's see how this goes. And yeah, we still do default exports now. I find it weird, but it's okay. And yeah, even like, I think a couple days ago, there was like a series of tweets where people were like copypasting the same tweet and tweeting default exports was a mistake in JavaScript, and I agree. But there's one hint, one trick that I want to show you. If you have actually someone, if you have a component that is a named export, and you cannot control it because it's coming from a library, you can actually use named. It looks ugly, it probably confuses the juniors out in your team, confuses the hell out of them, but still, there's a way to get it done. Yeah. Why you probably still want to, why we stick to default exports, because all the frameworks prefer named exports anyway. So yeah, it's kind of weird, but we can live with it.

Let's move on to the next topic, TypeScript. I love TypeScript. It's awesome. I love typing. The security of it, it's great. The one thing that I not always love is the react types.

Let me give you an example. When you start typing, your first React component, you learn, okay, there's React.function component, and you do it like this, and then realize, okay, but people don't use this. People use React.fc. And I was like, we don't have fun, funky, and funny for function as a keyword in JavaScript. Why do this? Why can't we have one way of doing things so you can teach one way, and you can learn one way, and you can be good with it? But this is not the end of the story because then, when you actually start to like read about how to type components, and so on and so forth, you realize a lot of experts, TypeScript experts, tell you like don't do React.fc.

So basically, and it all comes down to like mostly all of them complaining about one issue that existed in, yeah, spoiler alert, it's solved now. Basically, the types always implicitly, so this is what kind of happened, the implicities of React.fc added the implicit children. So if you had a component, like a model, that when you really need to have children, we expect them, you could pass them in or you could leave them out. But if you have other components where you don't even make use of children at all, you cannot declare it in any way because it will always be optionally there with React.fc. And so basically, what they proposed is use this instead. And you do this and you migrate your whole code base with your team, and then you onboard new juniors and they're really, really excited because they feel like, hey, they have an improvement that they can tell you about. Did you know there is a React.fc and we could migrate to this? And the only reaction is like, let's talk about something else. And you feel really bad for them. But it all changed. So by the way, the React types are not maintained by the React core team. But whoever is maintaining them, they made a really great decision because with React 2018 and breaking change, they sneaked in a change with their types, removing the implicit children. Ta-da. And I was like, hallelujah, solved all my problems, I can go back to React.fc. Why? Because if I have this here, if I have children, I have to now explicitly type them, or I can explicitly type them and basically say okay, childrens React note. And the thing that's happening here is if you look at this component, the component uses children, and you're basically expected to put in the children. If you do this, everything will be fine. But if you do this here, you will get a typescript error. So it will tell you like, hey, this component really only works well if you pass in children. So please pass in your children. And you can also do it the other way around. If you leave the children out at all, the beauty is if you do this, it will be fine. But if you do this here, it will give you a warning, hey, you should provide children. You should not provide children because this component doesn't accept any children. So this is a very neat trick. They really fix the types and it really fits my mental model of basically like I mean, this is Wikipedia, but the aim is to prevent operations expecting a certain kind of value from being used with values which that operation does not make sense.

You always want to have like TypeScript is a tool to help you to make sense of things and not like refresh and then figure out, oh, it doesn't actually use children at all. So that was really, really great. The weird thing or the weirdest thing about TypeScript types in React got actually fixed. The thing is now when you upgrade to React 18, you actually have to then change all of your components, and this is the pity again. Like, oh, God, now I have to go for hundreds of thousands of components and fix them, but there's a thing called code mod. Who of you has heard of code mods, JS Codeshift? Okay, a bunch of you. It's basically scripts that allow you to run over your whole code base and the cool thing is they will fix your code. So if you're running, if you're upgrading to React 18 and upgrade the types, you can basically just run this script on your source folder and it will be done and it updates everything. So what does it do? It takes this component, for example, and it updates it to this one, and I was like, yes, solved all my problems, and then I was like, on a second look, wait a second. This component doesn't actually use children. What are you seeing here? Props with children, and I thought, like, maybe I misused the script or I did something wrong, but I mean, you start investigating. So you look into this type, like what is props with children, and then you see the optional children in there again, and I felt like, why? Come on. Are you really doing this to me? Why are you doing this to me? At least, when you do this, have the dignity and call it props with optional children so I know what's going on. OK, so not perfect, better, let's say.

Next topic, let's talk about use effect. Oh, god. We all love use effect. I cannot fix use effect for you. The only thing that I can tell you is a lot of problems come because people don't use the cleanup function. At least, this is what I have seen. One thing that I find very annoying, the people often don't know that they should do a cleanup function and then they forget it and it's very easy to miss in a code review. So after a lot of frustration, eventually, we decided, let's do something about it. We could now do ESLint and whatnot, but the easiest way was, let's fix the actual React types because we can override it. This is how the React types for use effect basically look like, and what you can see here at the very top right on the second line is destruct.avoid. So basically, people can leave out the cleanup function and don't have to return it. Don't worry about the types too much. The one thing I want to tell you is what we could do is we could just fix them. We overwrite it and say, nope, void is not allowed. And then we can also fix the naming, because, come on, in all the documentation it says not destructor, it says cleanup function. So let's name it cleanup function. And then let's not call it effect callback because this is very unspecific. Let's call it use effect callback. I really like to, when I'm already in there, like to fix things anyway. And what does this give you? It's basically you have forced now to return a cleanup function. And so basically if you don't do it, it will give you a nice warning, hey, you're missing a cleanup function, basically. And so basically people have to do this. And yes, people still could do this. But if you see this in a code review, at least it's very visible that this is happening. So this is a nice little trick that I wanted to share. It doesn't make React less weird, but it at least makes our lives with effect saner. Which brings me to the next topic.

Warnings. I have a huge love and hate relationship with warnings. All of you probably know this one. Can't perform a React state update on unmounted component. You have dozens of them. This is actually good. I like it. Because it really tells you, hey, there's something you did wrong. You can clean it up. But we're not throwing an error, but we're at least giving you a warning. I'm okay with that. This is the love part more. I know I still hate them when I see them, because I know I did wrong. And yes, don't blame me, React. But at least I'm trying to clean up.

Okay. But the thing is, I can't stand it when it's coming from a package. This is so annoying. And I will show you. This is a real-world situation. This was two warnings that we had to go through every time we just wanted to look at our console logs. This is the second warning. It's like, it's a React Native Web application. Why do I have to go through this every time? It's coming from a package. Yes, I've reported already the issue. And yes, someone has to do it. But sometimes it's even really hard to reproduce. It's like, oh, god. And we—or at least I stood—I was okay with them for some time. And then I was like, at some point, I have to do something about it. I can't stand this anymore.

So I was trying to look up how can I fix this? How can we do something about it? And then I found something out that was very, very interesting, changing my life at least. Did you know you can patch console log? It's fantastic, love it. And yes, at this point, when I figured this out, I should have done the other thing and talk to my team and fix it. But the first thing we did—or I did—was figure out a way how to prank other people. So basically, overwriting console log by clearing the console in almost less than a second. So basically, we can paste this in here. And then whenever you try to log something out, you log it out and you want to inspect the output. And it clears away right away. Nice.

And you know, the important part of a good prank is, it should be annoying enough that they are annoyed, but they should not do something about it. They feel like, okay, I glanced the output, maybe this is good enough. It's a fine line to make it a good prank. And then, of course, I didn't want to make it too easy for everyone that encounters it. So I created another version where you can actually look in your code base and find anything that is related to console, log, or clear.

So you really make it hard. If you manage to get it into the code base, they will have a hard time finding this. Please use this. This is completely okay. I think so. I don't know. Don't sue me. And yeah.

So eventually, after I had enough fun, I went back to the adult thing. And I felt like, okay, let's actually do something about our annoying warnings. And we patched it. We created a little script that basically patches these warnings for specific components and so on. You can basically do a little bit of RegEx pattern matching.

And then I felt like, okay, I have to have conference talks this year. What do I do? This is something new. So let's create the library out of it, so I can actually have something to announce at the conferences. And this is it, React reduced stress. This really exists on NPM. There's also a GitHub repository. You can find it. You can use it. And yeah. You can simply get React reduced stress and suppress the warnings. And you can see, like, for the hooks order you can basically pass in which component. And for the unique key in list, yeah, we're using a library avatar group. They were doing something and messing up the children. It was like, oh, god, I reported it, but I'm not waiting anymore for new versions. And then some React native stuff that we also suppressed. So, yeah. You can use this.

This actually works. And if you have concerns, file it. And I put a lot of love into it. Like one evening, you know. But it works. And what does it give you? Peace of mind in your console. Ta-dah! Which brings me to a related topic.

And I think, yeah, this is the last one. So, enough with the logs, suppressing logs. But there's another one I want to mention. Who of you, the last weird thing, who of you uses React strict mode? Not too many. Why? Just kidding. So, because reasons. And this is actually copied from the official docs. I mean, most of it is basically just, like, legit reasons. If you have an old code, strict mode is good, because it helps you to identify what's going wrong and so on. But the thing is, there's two things that are brand new since React 18. Basically, detecting unexpected side effects and ensuring reusable state. And what it does is, if you're using strict mode in development in React 18, it re-renders your component twice, and it also runs the use effect and the use layer effect twice. I mean, the use layer effect usually runs only if you're committed to DOM, but apparently then it's rendered twice. I don't think it's actually committed twice to the DOM, but it's like running the use layer and use effect twice. This has a good purpose because a lot of us are abusing use effect and then doing things that should not run twice. If you enable strict mode, you will basically see a lot of use effect situations breaking. This is really annoying, but it has a purpose. A lot of new features that will come with React, like off-screen component and so on, You can prerender pages. Things that are not on the page don't have to be rendered. So you can have faster rendering, faster things on the DOM. Faster output on the DOM. All these kind of things expect use effect to not have any weird side effects and do things badly. But the problem is, I understand this, and OK, we basically need to clean up our code.

And I get this. But the problem is people don't get it. There is, like, no hint that this is happening. If you upgrade to React 18 or if you just install it in a new version, in a brand new project you have no information that why this is happening. And people don't get it. And this is a real conversation for a friend that basically lost the day because he was building a video player in his application. And like, I don't know what he did, but the mount effect, the mount use effect was basically the video player twice, and the video player could handle it, and yadda, yadda, yadda, and a couple of swear words that I had to black out. And I was like, why is there no, I mean, we have a console log for everything, but why is there no console log for this? You know? We are showing people if they don't have the DevTools and you're running in DevMode, we are showing them please install the DevTools, but we are not giving them any information about like why this double rendering is happening and you know why? It's only happening in DevMode, it's not happening in production. So you actually have like different behavior if you're running production or not. So this time I did the other thing, you know? I actually went to the repository of REG.js, I opened an issue, I proposed can we have a console log for this and so on. There was not much feedback, it's a couple weeks old. Nobody from the React team has seen it. But, I already have React Reduce Stress so I thought like, I can fix it myself. Because what you can do is, we can extend React Reduce Stress with Reduce Stress component that you can actually put into your code. So all the new juniors that will come along if you're using strict mode, so you can import Reduce Stress, you just have to add a component there. And what it will do is, if you're in strict mode in development mode, this is completely not doing anything, it will give you this hint. Because you're using strict mode in development, React will unmount and remount every component whenever the component mounts. Da-da-da. Basically helping your developers to figure out what is going on. And you know, again, I put a lot of love into it. Uh, two evenings or so. And it has a couple of features. SMDS, who have heard of it? Okay. Strict Mode Detection System. Where did I find this? It's actually in the React core. And you know what they do? They overwrite the console log to catch if the strict mode lock is happening. It's so awesome. It has dark mode support. For real. So the console, the red, is changing slightly in the console.

And it only supports modern browsers. So Firefox, Chrome, Brave and Edge. And we don't support Safari or Internet Explorer. Yeah. And this is basically it.

What's the conclusion for you? There was a lot of like mumble bumble. Read the React docs. Check out the RFCs. Read the working group. Have fun pranking someone with console lock. And install React Reduce Stress.

And despite having, like this was a 30-minute rant here. I want to say it's been quite a ride. I learned a lot. It was a lot of fun. And I will actually stick around. React is awesome. It has its flaws. But it is a super interesting journey. And I learned a lot. And I'm Nick Graf. And I hope you enjoyed today. Thank you very much. Amazing. Thank you so much, Nick. Is this thing on? Please step into my office. We have a couple minutes only. But there are a couple questions on the Slido from the audience. Remember it's slide.do and the code is 0212 if you want to ask a question. Nick, when we teach new React devs, should they learn about these weirdnesses or should we hide that until they are over the point of no return? Definitely over the point of no return.

You're not going to a date and tell the weirdest thing about you. Yeah, I think yes. You want to have a subtle introduction. And then you can tell people more on time. Use effect is something you have to tell them right away. And maybe if someone is new to React, don't introduce them to use effect right away. But keep that to the back and focus on the things that are easy and keep people going. You want to keep up the happiness because this is how people learn best, I think. I think that's a good advice.

The other question we have is how do you detect if the app is currently running in strict mode? It's really this, there's a console log. I mean just check out the code. But you basically, there's a console log that is happening I think, and then you do it like this. Oh yeah, oh, no. It's a warning from a legacy component that is basically deprecated. So we are detecting if the legacy component is, so the React Reduced REST uses the legacy component that should be deprecated, and then it throws a warning and we're detecting if the warning is thrown, and this is how we're detecting strict mode is running. It's nuts. But this is in a React core test, so I was like, OK, this seems to be the best way. Let's copy and paste it. There's no internal hidden variable that you can use to figure it out. Yeah, fair.

There's a couple of interesting like side questions. What's your take on re-script at this stage? So for context, I was part of the early Reason.ml community, and re-script is basically a successor to it, and yeah, I love re-script. I love good type systems, and it's really great, but right now I'm not using it. Just because, like, I'm having a product and I have developers that were familiar with TypeScript, but not re-script, and then, like, onboarding them to re-script would have taken a lot of time, and then in the end it was a very practical decision to not go with it. I mean, I love type systems, I love to write clean code, but yeah, sometimes the practical thing is just easier and better. It made more sense.

That makes sense, sometimes you have to be practical. That is about all the time we have for questions, but Nick will be in the speaker room by the reception for in real life one to one questions. Thank you, Nick.