The Weird Things About React

Rate this content
Bookmark

Conditional rendering issues in JSX, forwardRef, serveral ways to create refs, render props (yeah they still exist), higher-order components (do they still exist?), act, non-extendable classes, SuspenseList (well, maybe in 10 years), React.FC and of course our good old friend useEffect. All these weird things are part of our favourite library (not a framework™) and yet we still use and love it. Why actually? Let's talk about. Disclaimer: This is not a very serious talk, mostly …

34 min
02 Dec, 2022

Video Summary and Transcription

React has some weird and undocumented features like using the key attribute to remount components. The new beta docs and RFCs provide valuable insights into React's thinking and allow for proposing changes. React's composition story has evolved from mixins to higher order components to hooks. The upgrade to React 18 fixed TypeScript types but introduced issues with optional children. React warnings can be helpful but also annoying, and a library called React Reduce Stress can suppress them. React strict mode helps identify issues and supports new features, but it can cause double rendering in React 18. Overall, React is an interesting journey with its flaws and learning opportunities.

Available in Español

1. Introduction to React and Key Attribute

Short description:

Let's talk about the weird things about React. My journey with React started with version 0.12 or 0.13. 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. Let me give you a couple of examples. Did you know you can use the key attribute to basically remount components? This is nowhere on the official docs, but once I figured this out, it was fantastic.

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.

2. React's Missing Documentation

Short description:

I wrote a blog post about it, telling people not to use it. But it's inside information that can be leveraged if you know about it. Sebastian explains on Twitter that it's a valid use case. I found it weird that it's not in the official docs, but Dan said he'll keep it in mind for the rewrite.

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.

3. The Importance of Reading the Beta Docs

Short description:

The new beta docs are excellent. You can still learn something from them, even if you've been using React for years. I highly recommend reading the docs.

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.

4. React's Undefined Return and RFCs

Short description:

Since 2018, you can return a render undefined and return undefined in React components. This change was mentioned in an official blog post, but without any explanation. It took some time, but eventually, an explanation was released on the RFCs. The RFCs are a new React RFC thingy that provides insights into the thinking behind React and allows users to propose changes. The beta talks and RFCs help address the unofficial talk problem.

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.

5. React's Composition and Higher Order Components

Short description:

Another weird thing about React is composition. It started with mixins, which provided two-way data binding. However, a blog post labeled mixins as harmful, leaving developers with the choice to refactor or move on. The solution was higher order components, which allowed for composition but proved to be unmaintainable. Eventually, Twitter joined the React team and announced that higher order components are a bad idea.

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.

6. React Composition and Hooks

Short description:

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. Then we had render props and I really hated them. So then we got our savior, hooks. 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. But hooks is actually, I'm okay with it. Like hooks are good. They have a clear rule set. 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.

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.

7. Named Exports and React Lazy

Short description:

I love named exports, but React Lazy introduced the need for default exports. We tried other frameworks like Angular, but returned to React. Default exports may seem weird, but there's a trick using named exports for components from libraries. However, frameworks prefer named exports. Now, let's talk about TypeScript. I love TypeScript for its typing and security, but the react types can be challenging at times.

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.

8. React.fc and Implicit Children

Short description:

When you start typing your first React component, you may come across React.fc and wonder why there isn't a consistent way of doing things. TypeScript experts advise against using React.fc due to an issue with implicit children. However, the React types were updated in 2018 to remove implicit children, allowing for explicit typing. This change ensures that components using children are properly typed, while components not accepting children generate warnings. The aim is to prevent operations expecting a certain kind of value from being used with values which that operation does not make sense.

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.

9. TypeScript Types and React 18 Upgrade

Short description:

TypeScript types in React got fixed with the upgrade to React 18. Changing all components can be done with code mods, like JS Codeshift. However, the issue with the 'props with children' type persists, with optional children causing confusion.

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.

10. Fixing React Types for Use Effect

Short description:

Let's talk about use effect. A lot of problems come from people not using the cleanup function. We decided to fix the React types for use effect, forcing the return of a cleanup function. This provides a nice warning if it's missing, making it more visible in code reviews. It doesn't make React less weird, but it makes our lives with effect saner.

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.

11. React Warnings and Unmounted Components

Short description:

I have a huge love and hate relationship with warnings. Can't perform a React state update on unmounted component. This is actually good. 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.

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.

12. Fixing Annoying Warnings and Console Pranks

Short description:

I discovered a way to fix the annoying warnings that come from a package. By patching the console log, I was able to clear the console almost instantly. This allowed me to play pranks on my colleagues, but it also highlighted the need to address the issue. I even created a version that helps identify console-related code in the codebase.

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.

13. React Reduced Stress Library

Short description:

So eventually, after I had enough fun, I went back to the adult thing. And we patched it. We created a little script that basically patches these warnings for specific components and so on. And then I felt like, okay, I have to have conference talks this year. What do I do? So let's create the library out of it, so I can actually have something to announce at the conferences. This is it, React reduced stress. It really exists on NPM. You can find it. You can use it. You can simply get React reduced stress and suppress the warnings.

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.

14. React Strict Mode and Use Effect

Short description:

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! There's another one I want to mention. Who of you uses React strict mode? Not too many. Why? Just kidding. So, because 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 there's two things that are brand new since React 18. Basically, detecting unexpected side effects and ensuring reusable state. 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. 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, expect use effect to not have any weird side effects and do things badly. But the problem is, we basically need to clean up our code.

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.

15. React Double Rendering and Strict Mode

Short description:

People often struggle to understand why double rendering occurs in React 18. The lack of information and console logs makes it difficult to diagnose the issue, especially in development mode. To address this, I proposed adding a console log to the React repository, but received limited feedback. As a solution, I extended React Reduce Stress with the Reduce Stress component, which provides a hint when using strict mode in development. This component helps developers understand that React will unmount and remount every component on mount. The Strict Mode Detection System in the React core detects the strict mode lock and even supports dark mode in the console.

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.

QnA

Conclusion and Q&A

Short description:

And it only supports modern browsers. What's the conclusion for you? Read the React docs. Check out the RFCs. Read the working group. Have fun pranking someone with console lock. And install React Reduce Stress. It's been quite a ride. React is awesome. It has its flaws. But it is a super interesting journey. And I learned a lot. Thank you very much.

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.

Subtle Introduction and Strict Mode Detection

Short description:

You want to have a subtle introduction and focus on the easy things to keep people engaged. Detecting strict mode involves checking for a warning from a deprecated legacy component. There's no internal hidden variable for this. Regarding re-script, while it has a great type system, practical considerations led to not using it. Sometimes being practical is easier and better.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
Top Content
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn