React is a minimal on the surface, but it’s actually a highly complex JavaScript UI library with many potential pitfalls. In this tutorial, we look at 10 antipatterns in React, along with tips and tricks to improve our code. https://fireship.io/courses/react

#react #js #CodeThisNotThat

🔥  Use this discount code to get 33% off Fireship PRO:

hh7F4Ezs

https://fireship.io/pro


🔗 Resources

React Docs https://reactjs.org
Full React Course https://fireship.io/courses/react
React in 100 Seconds https://youtu.be/Tn6-PIqc4UM

📚 Chapters

00:00 React Antipatterns
01:00 1. Big Components
01:55 2. Nesting Gotcha
02:35 3. Failure to Memoize
03:15 4. Useless Divs
03:44 5. Messy Files
04:40 6. Big Bundles
05:34 7. Prop Drilling
06:30 8. Prop Plowing
07:00 9. Try Some Curry
07:39 10. Code Smarter

🎨 My Editor Settings

- Atom One Dark 
- vscode-icons
- Fira Code Font

🔖 Topics Covered

- React Pitfalls
- React Code Smell
- Problems with React.js
- React Best Practices
- Structure a react project
- Antipatterns in react to avoid
- React tips and tricks
- React interview tips
2024-02-04T05:32:51.271Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
123e6b95-bd34-49ca-9ac3-af4fa0f96dea
3473e9efb428f79508ea531e05bcb7af976620fb3b38944ae7b8e693a980fe3a
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
React JS is elegant and minimal on the surface.
Just write a JavaScript function to represent a component that automatically renders when your data changes.
It's simple, but also misleading.
In reality, React is a highly complex UI library with a good amount of technical baggage that has accumulated over the last a decade.
Many newer frameworks attempt to do things better, but React is still the king.
And if you wanna be a web developer in 2022, it's a very good idea to learn it.
The problem is that React is unopinionated yet provides many different ways to solve the same problems.
That leaves us developers with plenty of room to screw things up with our own stupid ideas.
In today's episode out of code this, not that.
We'll look at 10 anti patterns in React, along with tips and tricks to improve our code, and also prepare for a front end technical interview.
Before we get started, I have an announcement.
I'm working on a brand new course for pro members that teaches the fundamentals of React in my 100 seconds of code format, then puts those concepts to use by building multiple full stack applications in scratch.
The course is not finished yet, but I'll be releasing new videos for it every couple days on FireShip IO.
When I initially start building a React app, I usually start by writing 1 big giant any component, often in the app component provided by create react app.
And that's intentional because I usually don't know how I want my code to be organized initially and I don't want to waste my time over organizing things before I even know what I wanna do.
However, this results in an anti pattern of having one overly large deeply nested component.
A component like this is hard to understand, re Factor and test.
We can improve this code by refactoring into reusable components, like this navbar could easily be broken down into 1 or or components that better represent what it does.
Now that may sound like a lot of work, but luckily, there's a Versus code extension called glean that can leverage the IDE to do this work for us.
Install it, then highlight the code you want to extract into its own component, click the light bulb, and you'll see a bunch of options to refactor like render conditionally it or extract component.
Give it a name, then it will automatically move the code while including the required props.
It's a massive time saver that I couldn't imagine and without.
Now, when you start refactoring a large component, you might be tempted into another anti pattern of nesting components.
In this example, we've defined a child component that lives inside the parent component.
The child uses a function defined in the parent and by defining it here, we don't need to provide a prop for that function.
It feels very intuitive and it works perfectly fine.
But there's a major problem here.
Every time the parent component is rendered, it will also redefine the child component, which means it gets a new memory address and that could lead to performance issues and unpredictable behavior.
The solution is to either not define a child component at all or to move the child component out of the parent and pass the function in as a prop.
This example demonstrates how react is very simple on the surface, but if you don't know exactly what's going on, it's easy to shoot yourself in but here's a similar example of a component that does too much work and might end up causing performance issues.
Let's imagine we have a component with 2 different pieces of state.
On one piece of date, we need to run an expensive calculation anytime the value changes.
The problem with our current implementation is that anytime the state changes on this component, It will rerun the expensive calculation even though it only depends on the one count value.
It's not very obvious, but you have a potential performance bottleneck air.
In a situation like this, you'll want to use the use memo hook.
What it will do is remember the last value and only run the actual and when it's dependent data changes.
You might also run into the situation when working with functions, and for that, React provides a useCallback hook.
Now another thing you might run into is that when defining a brand new component, you get an error when trying to return 2 sibling elements together.
That's because every component can have only one root element.
So what you might do is wrap it with a div.
That works perfectly fine, but it leads to a bunch of unnecessary divs in in markup, and that can cause issues with accessibility and CSS styling.
To address this concern, React has a built in fragment component, or better yet, You can use the shorthand syntax of an empty element, which tells React to render nothing as the parent element.
Now, as your app grows in complexity and you start creating more and more components, You'll want to have an opinionated way to organize them.
A good rule to follow is 1 component per file.
It can be tempting to export multiple components from a single a file, but things will get pretty complicated quickly.
If a component is going to be exported, it's generally best that it lives in its own file.
Now, in larger projects, I would take things one step further and give every component its own directory.
If you name the file index, then you can easily export it from that directory.
But inside the directory, you can add other files like a CSS module for Example, or anything else you might need for testing, Storybook, TypeScript, and so on.
This is how they do things by default in Angular, and I find it works really well for large projects.
Now, there is one drawback when naming your component index, and that's the fact that it's kind of confusing when working with tabs in your IDE.
What you can do is give your component file a regular a name, then use the index file to export it.
That's called a barrel, and it will keep your imports nice and concise while also providing a readable file name for the IDE.
One of the biggest problems with Big complex apps though, is that they're big.
And what that means is that when you ship your app to production, it'll have a slow initial page load because it takes a long time The browser to download the JavaScript bundle.
So what can we do about that?
If you're using a tool like Next.
Js or create react app, which are built on top of webpack, it's very easy to Implement code splitting.
Normally, to import code, you use an import statement.
However, browsers now support dynamic imports, which allows you to load a module asynchronously using the import function.
When webpack sees that code, it automatically knows to split that code into a different bundle, which won't be required until after the initial page load.
That works fine for plain JavaScript, but not so much when it comes to React components.
However, React has a feature to support lazy loading, which is still experimental today, but it allows you to use dynamic imports on React components.
Once a component is dynamically imported, you can then wrap it in the suspense component to show a fallback UI when it's loading.
It.
Now, another problem you might run into with big projects is that you might have one component at the very top that holds your state, but then you have a deeply nested component that also needs to use that state.
What you have to do is then pass that state as a prop to a bunch of intermediate components that don't actually need it until it finally gets to that child.
This is known as prop drilling because it makes you want to drill a whole into your brain.
One solution is to bring in a state management library like Redux, but that's a heavy handed approach.
When you have global data that's used everywhere, like an authenticated user for example, you can share it everywhere with the context API.
You first provide the data at a certain point in the component tree, then any component nested under it at any level can and access that data.
Sounds awesome, but it does come at a cost.
The context API is something that you should use sparingly because it makes your components impossible to reuse without having that provider or as a parent.
Most apps only have a handful of values that are truly global.
That stuff can go into context while everything else should be more localized.
Prop drilling is a vertical problem, but you might also end up with a horizontal problem called prop plowing, which is a term I just made up.
What might happen is that you end up with components that have a lot out of different props, and you end up with this long repetitive code where each prop has the same name as the variable passed to it.
When you have an object that contains all the props that you're passing to the child, You can use the spread syntax to pass them all at the same time.
That makes your code much more concise, and personally, I'm a big fan of this.
However, It does make your code less explicit, so I typically only recommend using it when you have a component with a ton of props that really justifies its use.
Another area where your React code can get pretty messy is with Event handlers in JSX.
What happens is you might have a function that takes the event as its first argument, but one or more other values as secondary arguments.
That means to call it, You'll need to break out an arrow function and this can get pretty messy if used in multiple places.
A cool little JavaScript trick here is to create a curried function.
It.
Basically, it's just a function that returns another function.
The outer function takes our custom arguments, while the inner function handles the event that's passed by default.
This Eliminates the need to define an arrow function for each event.
Not only does that make your code look a lot cleaner, but it also gives you a legitimate use case for occurring, which will impress your friends and family.
And that brings us to anti pattern number 10.
When working with the useState hook in a component, it's tempting to put all of your data in a single object.
It.
It makes the code look cleaner and may also seem more performant because you only need to call set state once.
However, what you should know is that React 18 will do automatic batching whenever you update the state.
That means calling setState multiple times in the same function will not trigger multiple re renders.
Therefore, it's not a big deal for performance, but more importantly, it makes your code difficult to extract into a custom hook.
In the olden days with React class components, it was common to organize your code into smart components and dumb components, where the smart components control the data and the dumb components just render UI with props.
There's nothing wrong with this pattern, but nowadays it's It's easier to just extract your logic into a custom hook.
What I like to do is build my component with a bunch of different stateful values at first, Then if things get too complex, or I want to use that code in a different component, I extract it into my own custom hook, which itself is just a JavaScript function.
It.
This allows you to treat virtually all your components as dumb components, while your custom hooks handle the more complex business logic.
And with that, we've looked at a small preview of the different things you can screw up in React.
Check out my full course if you wanna learn more about React, and here's a special discount for making it all the way to the end of this video.
Thanks for watching, and I will see you in the next one.

Speaker 0: React JS is elegant and minimal on the surface. Just write a JavaScript function to represent a component that automatically renders when your data changes. It's simple, but also misleading. In reality, React is a highly complex UI library with a good amount of technical baggage that has accumulated over the last a decade. Many newer frameworks attempt to do things better, but React is still the king.

And if you wanna be a web developer in 2022, it's a very good idea to learn it. The problem is that React is unopinionated yet provides many different ways to solve the same problems. That leaves us developers with plenty of room to screw things up with our own stupid ideas. In today's episode out of code this, not that. We'll look at 10 anti patterns in React, along with tips and tricks to improve our code, and also prepare for a front end technical interview.

Before we get started, I have an announcement. I'm working on a brand new course for pro members that teaches the fundamentals of React in my 100 seconds of code format, then puts those concepts to use by building multiple full stack applications in scratch. The course is not finished yet, but I'll be releasing new videos for it every couple days on FireShip IO. When I initially start building a React app, I usually start by writing 1 big giant any component, often in the app component provided by create react app. And that's intentional because I usually don't know how I want my code to be organized initially and I don't want to waste my time over organizing things before I even know what I wanna do.

However, this results in an anti pattern of having one overly large deeply nested component. A component like this is hard to understand, re Factor and test. We can improve this code by refactoring into reusable components, like this navbar could easily be broken down into 1 or or components that better represent what it does. Now that may sound like a lot of work, but luckily, there's a Versus code extension called glean that can leverage the IDE to do this work for us. Install it, then highlight the code you want to extract into its own component, click the light bulb, and you'll see a bunch of options to refactor like render conditionally it or extract component.

Give it a name, then it will automatically move the code while including the required props. It's a massive time saver that I couldn't imagine and without. Now, when you start refactoring a large component, you might be tempted into another anti pattern of nesting components. In this example, we've defined a child component that lives inside the parent component. The child uses a function defined in the parent and by defining it here, we don't need to provide a prop for that function.

It feels very intuitive and it works perfectly fine. But there's a major problem here. Every time the parent component is rendered, it will also redefine the child component, which means it gets a new memory address and that could lead to performance issues and unpredictable behavior. The solution is to either not define a child component at all or to move the child component out of the parent and pass the function in as a prop. This example demonstrates how react is very simple on the surface, but if you don't know exactly what's going on, it's easy to shoot yourself in but here's a similar example of a component that does too much work and might end up causing performance issues.

Let's imagine we have a component with 2 different pieces of state. On one piece of date, we need to run an expensive calculation anytime the value changes. The problem with our current implementation is that anytime the state changes on this component, It will rerun the expensive calculation even though it only depends on the one count value. It's not very obvious, but you have a potential performance bottleneck air. In a situation like this, you'll want to use the use memo hook.

What it will do is remember the last value and only run the actual and when it's dependent data changes. You might also run into the situation when working with functions, and for that, React provides a useCallback hook. Now another thing you might run into is that when defining a brand new component, you get an error when trying to return 2 sibling elements together. That's because every component can have only one root element. So what you might do is wrap it with a div.

That works perfectly fine, but it leads to a bunch of unnecessary divs in in markup, and that can cause issues with accessibility and CSS styling. To address this concern, React has a built in fragment component, or better yet, You can use the shorthand syntax of an empty element, which tells React to render nothing as the parent element. Now, as your app grows in complexity and you start creating more and more components, You'll want to have an opinionated way to organize them. A good rule to follow is 1 component per file. It can be tempting to export multiple components from a single a file, but things will get pretty complicated quickly.

If a component is going to be exported, it's generally best that it lives in its own file. Now, in larger projects, I would take things one step further and give every component its own directory. If you name the file index, then you can easily export it from that directory. But inside the directory, you can add other files like a CSS module for Example, or anything else you might need for testing, Storybook, TypeScript, and so on. This is how they do things by default in Angular, and I find it works really well for large projects.

Now, there is one drawback when naming your component index, and that's the fact that it's kind of confusing when working with tabs in your IDE. What you can do is give your component file a regular a name, then use the index file to export it. That's called a barrel, and it will keep your imports nice and concise while also providing a readable file name for the IDE. One of the biggest problems with Big complex apps though, is that they're big. And what that means is that when you ship your app to production, it'll have a slow initial page load because it takes a long time The browser to download the JavaScript bundle.

So what can we do about that? If you're using a tool like Next. Js or create react app, which are built on top of webpack, it's very easy to Implement code splitting. Normally, to import code, you use an import statement. However, browsers now support dynamic imports, which allows you to load a module asynchronously using the import function.

When webpack sees that code, it automatically knows to split that code into a different bundle, which won't be required until after the initial page load. That works fine for plain JavaScript, but not so much when it comes to React components. However, React has a feature to support lazy loading, which is still experimental today, but it allows you to use dynamic imports on React components. Once a component is dynamically imported, you can then wrap it in the suspense component to show a fallback UI when it's loading. It.

Now, another problem you might run into with big projects is that you might have one component at the very top that holds your state, but then you have a deeply nested component that also needs to use that state. What you have to do is then pass that state as a prop to a bunch of intermediate components that don't actually need it until it finally gets to that child. This is known as prop drilling because it makes you want to drill a whole into your brain. One solution is to bring in a state management library like Redux, but that's a heavy handed approach. When you have global data that's used everywhere, like an authenticated user for example, you can share it everywhere with the context API.

You first provide the data at a certain point in the component tree, then any component nested under it at any level can and access that data. Sounds awesome, but it does come at a cost. The context API is something that you should use sparingly because it makes your components impossible to reuse without having that provider or as a parent. Most apps only have a handful of values that are truly global. That stuff can go into context while everything else should be more localized.

Prop drilling is a vertical problem, but you might also end up with a horizontal problem called prop plowing, which is a term I just made up. What might happen is that you end up with components that have a lot out of different props, and you end up with this long repetitive code where each prop has the same name as the variable passed to it. When you have an object that contains all the props that you're passing to the child, You can use the spread syntax to pass them all at the same time. That makes your code much more concise, and personally, I'm a big fan of this. However, It does make your code less explicit, so I typically only recommend using it when you have a component with a ton of props that really justifies its use.

Another area where your React code can get pretty messy is with Event handlers in JSX. What happens is you might have a function that takes the event as its first argument, but one or more other values as secondary arguments. That means to call it, You'll need to break out an arrow function and this can get pretty messy if used in multiple places. A cool little JavaScript trick here is to create a curried function. It.

Basically, it's just a function that returns another function. The outer function takes our custom arguments, while the inner function handles the event that's passed by default. This Eliminates the need to define an arrow function for each event. Not only does that make your code look a lot cleaner, but it also gives you a legitimate use case for occurring, which will impress your friends and family. And that brings us to anti pattern number 10.

When working with the useState hook in a component, it's tempting to put all of your data in a single object. It. It makes the code look cleaner and may also seem more performant because you only need to call set state once. However, what you should know is that React 18 will do automatic batching whenever you update the state. That means calling setState multiple times in the same function will not trigger multiple re renders.

Therefore, it's not a big deal for performance, but more importantly, it makes your code difficult to extract into a custom hook. In the olden days with React class components, it was common to organize your code into smart components and dumb components, where the smart components control the data and the dumb components just render UI with props. There's nothing wrong with this pattern, but nowadays it's It's easier to just extract your logic into a custom hook. What I like to do is build my component with a bunch of different stateful values at first, Then if things get too complex, or I want to use that code in a different component, I extract it into my own custom hook, which itself is just a JavaScript function. It.

This allows you to treat virtually all your components as dumb components, while your custom hooks handle the more complex business logic. And with that, we've looked at a small preview of the different things you can screw up in React. Check out my full course if you wanna learn more about React, and here's a special discount for making it all the way to the end of this video. Thanks for watching, and I will see you in the next one.
React JS is elegant and minimal on the surface. Just write a JavaScript function to represent a component that automatically renders when your data changes. It's simple, but also misleading. In reality, React is a highly complex UI library with a good amount of technical baggage that has accumulated over the last a decade.
Many newer frameworks attempt to do things better, but React is still the king. And if you wanna be a web developer in 2022, it's a very good idea to learn it. The problem is that React is unopinionated yet provides many different ways to solve the same problems. That leaves us developers with plenty of room to screw things up with our own stupid ideas.
software development
In today's episode out of code this, not that. We'll look at 10 anti patterns in React, along with tips and tricks to improve our code, and also prepare for a front end technical interview.
Before we get started, I have an announcement. I'm working on a brand new course for pro members that teaches the fundamentals of React in my 100 seconds of code format, then puts those concepts to use by building multiple full stack applications in scratch. The course is not finished yet, but I'll be releasing new videos for it every couple days on FireShip IO.
software development
When I initially start building a React app, I usually start by writing 1 big giant any component, often in the app component provided by create react app. And that's intentional because I usually don't know how I want my code to be organized initially and I don't want to waste my time over organizing things before I even know what I wanna do. However, this results in an anti pattern of having one overly large deeply nested component. A component like this is hard to understand, re Factor and test.
We can improve this code by refactoring into reusable components, like this navbar could easily be broken down into 1 or or components that better represent what it does. Now that may sound like a lot of work, but luckily, there's a Versus code extension called glean that can leverage the IDE to do this work for us. Install it, then highlight the code you want to extract into its own component, click the light bulb, and you'll see a bunch of options to refactor like render conditionally it or extract component. Give it a name, then it will automatically move the code while including the required props.
software
programming
software development
It's a massive time saver that I couldn't imagine and without.
Now, when you start refactoring a large component, you might be tempted into another anti pattern of nesting components. In this example, we've defined a child component that lives inside the parent component. The child uses a function defined in the parent and by defining it here, we don't need to provide a prop for that function. It feels very intuitive and it works perfectly fine. But there's a major problem here. Every time the parent component is rendered, it will also redefine the child component, which means it gets a new memory address and that could lead to performance issues and unpredictable behavior. The solution is to either not define a child component at all or to move the child component out of the parent and pass the function in as a prop.
parenting
infants
children
This example demonstrates how react is very simple on the surface, but if you don't know exactly what's going on, it's easy to shoot yourself in but here's a similar example of a component that does too much work and might end up causing performance issues. Let's imagine we have a component with 2 different pieces of state. On one piece of date, we need to run an expensive calculation anytime the value changes. The problem with our current implementation is that anytime the state changes on this component, It will rerun the expensive calculation even though it only depends on the one count value. It's not very obvious, but you have a potential performance bottleneck air. In a situation like this, you'll want to use the use memo hook. What it will do is remember the last value and only run the actual and when it's dependent data changes. You might also run into the situation when working with functions, and for that, React provides a useCallback hook. Now another thing you might run into is that when defining a brand new component, you get an error when trying to return 2 sibling elements together. That's because every component can have only one root element. So what you might do is wrap it with a div. That works perfectly fine, but it leads to a bunch of unnecessary divs in in markup, and that can cause issues with accessibility and CSS styling. To address this concern, React has a built in fragment component, or better yet, You can use the shorthand syntax of an empty element, which tells React to render nothing as the parent element. Now, as your app grows in complexity and you start creating more and more components, You'll want to have an opinionated way to organize them. A good rule to follow is 1 component per file. It can be tempting to export multiple components from a single a file, but things will get pretty complicated quickly. If a component is going to be exported, it's generally best that it lives in its own file. Now, in larger projects, I would take things one step further and give every component its own directory. If you name the file index, then you can easily export it from that directory. But inside the directory, you can add other files like a CSS module for Example, or anything else you might need for testing, Storybook, TypeScript, and so on. This is how they do things by default in Angular, and I find it works really well for large projects. Now, there is one drawback when naming your component index, and that's the fact that it's kind of confusing when working with tabs in your IDE. What you can do is give your component file a regular a name, then use the index file to export it. That's called a barrel, and it will keep your imports nice and concise while also providing a readable file name for the IDE. One of the biggest problems with Big complex apps though, is that they're big. And what that means is that when you ship your app to production, it'll have a slow initial page load because it takes a long time The browser to download the JavaScript bundle. So what can we do about that? If you're using a tool like Next. Js or create react app, which are built on top of webpack, it's very easy to Implement code splitting.
Normally, to import code, you use an import statement. However, browsers now support dynamic imports, which allows you to load a module asynchronously using the import function. When webpack sees that code, it automatically knows to split that code into a different bundle, which won't be required until after the initial page load.
shipping
That works fine for plain JavaScript, but not so much when it comes to React components. However, React has a feature to support lazy loading, which is still experimental today, but it allows you to use dynamic imports on React components. Once a component is dynamically imported, you can then wrap it in the suspense component to show a fallback UI when it's loading.
animation
It. Now, another problem you might run into with big projects is that you might have one component at the very top that holds your state, but then you have a deeply nested component that also needs to use that state.
What you have to do is then pass that state as a prop to a bunch of intermediate components that don't actually need it until it finally gets to that child. This is known as prop drilling because it makes you want to drill a whole into your brain. One solution is to bring in a state management library like Redux, but that's a heavy handed approach.
construction
When you have global data that's used everywhere, like an authenticated user for example, you can share it everywhere with the context API. You first provide the data at a certain point in the component tree, then any component nested under it at any level can and access that data.
data
databases
data management
Sounds awesome, but it does come at a cost. The context API is something that you should use sparingly because it makes your components impossible to reuse without having that provider or as a parent. Most apps only have a handful of values that are truly global. That stuff can go into context while everything else should be more localized. Prop drilling is a vertical problem, but you might also end up with a horizontal problem called prop plowing, which is a term I just made up. What might happen is that you end up with components that have a lot out of different props, and you end up with this long repetitive code where each prop has the same name as the variable passed to it. When you have an object that contains all the props that you're passing to the child, You can use the spread syntax to pass them all at the same time. That makes your code much more concise, and personally, I'm a big fan of this. However, It does make your code less explicit, so I typically only recommend using it when you have a component with a ton of props that really justifies its use. Another area where your React code can get pretty messy is with Event handlers in JSX. What happens is you might have a function that takes the event as its first argument, but one or more other values as secondary arguments. That means to call it, You'll need to break out an arrow function and this can get pretty messy if used in multiple places. A cool little JavaScript trick here is to create a curried function. It. Basically, it's just a function that returns another function. The outer function takes our custom arguments, while the inner function handles the event that's passed by default. This Eliminates the need to define an arrow function for each event. Not only does that make your code look a lot cleaner, but it also gives you a legitimate use case for occurring, which will impress your friends and family. And that brings us to anti pattern number 10. When working with the useState hook in a component, it's tempting to put all of your data in a single object. It. It makes the code look cleaner and may also seem more performant because you only need to call set state once. However, what you should know is that React 18 will do automatic batching whenever you update the state.
That means calling setState multiple times in the same function will not trigger multiple re renders. Therefore, it's not a big deal for performance, but more importantly, it makes your code difficult to extract into a custom hook. In the olden days with React class components, it was common to organize your code into smart components and dumb components, where the smart components control the data and the dumb components just render UI with props.
programming
There's nothing wrong with this pattern, but nowadays it's It's easier to just extract your logic into a custom hook. What I like to do is build my component with a bunch of different stateful values at first, Then if things get too complex, or I want to use that code in a different component, I extract it into my own custom hook, which itself is just a JavaScript function.
programming
It. This allows you to treat virtually all your components as dumb components, while your custom hooks handle the more complex business logic. And with that, we've looked at a small preview of the different things you can screw up in React. Check out my full course if you wanna learn more about React, and here's a special discount for making it all the way to the end of this video. Thanks for watching, and I will see you in the next one.
React JS is elegant and minimal on the surface. Just write a JavaScript function to represent a component that automatically renders when your data changes. It's simple, but also misleading. In reality, React is a highly complex UI library with a good amount of technical baggage that has accumulated over the last a decade. Many newer frameworks attempt to do things better, but React is still the king. And if you wanna be a web developer in 2022, it's a very good idea to learn it. The problem is that React is unopinionated yet provides many different ways to solve the same problems. That leaves us developers with plenty of room to screw things up with our own stupid ideas. In today's episode out of code this, not that. We'll look at 10 anti patterns in React, along with tips and tricks to improve our code, and also prepare for a front end technical interview. Before we get started, I have an announcement. I'm working on a brand new course for pro members that teaches the fundamentals of React in my 100 seconds of code format, then puts those concepts to use by building multiple full stack applications in scratch. The course is not finished yet, but I'll be releasing new videos for it every couple days on FireShip IO. When I initially start building a React app, I usually start by writing 1 big giant any component, often in the app component provided by create react app. And that's intentional because I usually don't know how I want my code to be organized initially and I don't want to waste my time over organizing things before I even know what I wanna do. However, this results in an anti pattern of having one overly large deeply nested component. A component like this is hard to understand, re Factor and test. We can improve this code by refactoring into reusable components, like this navbar could easily be broken down into 1 or or components that better represent what it does. Now that may sound like a lot of work, but luckily, there's a Versus code extension called glean that can leverage the IDE to do this work for us. Install it, then highlight the code you want to extract into its own component, click the light bulb, and you'll see a bunch of options to refactor like render conditionally it or extract component. Give it a name, then it will automatically move the code while including the required props. It's a massive time saver that I couldn't imagine and without. Now, when you start refactoring a large component, you might be tempted into another anti pattern of nesting components. In this example, we've defined a child component that lives inside the parent component. The child uses a function defined in the parent and by defining it here, we don't need to provide a prop for that function. It feels very intuitive and it works perfectly fine. But there's a major problem here. Every time the parent component is rendered, it will also redefine the child component, which means it gets a new memory address and that could lead to performance issues and unpredictable behavior. The solution is to either not define a child component at all or to move the child component out of the parent and pass the function in as a prop. This example demonstrates how react is very simple on the surface, but if you don't know exactly what's going on, it's easy to shoot yourself in but here's a similar example of a component that does too much work and might end up causing performance issues. Let's imagine we have a component with 2 different pieces of state. On one piece of date, we need to run an expensive calculation anytime the value changes. The problem with our current implementation is that anytime the state changes on this component, It will rerun the expensive calculation even though it only depends on the one count value. It's not very obvious, but you have a potential performance bottleneck air. In a situation like this, you'll want to use the use memo hook. What it will do is remember the last value and only run the actual and when it's dependent data changes. You might also run into the situation when working with functions, and for that, React provides a useCallback hook. Now another thing you might run into is that when defining a brand new component, you get an error when trying to return 2 sibling elements together. That's because every component can have only one root element. So what you might do is wrap it with a div. That works perfectly fine, but it leads to a bunch of unnecessary divs in in markup, and that can cause issues with accessibility and CSS styling. To address this concern, React has a built in fragment component, or better yet, You can use the shorthand syntax of an empty element, which tells React to render nothing as the parent element. Now, as your app grows in complexity and you start creating more and more components, You'll want to have an opinionated way to organize them. A good rule to follow is 1 component per file. It can be tempting to export multiple components from a single a file, but things will get pretty complicated quickly. If a component is going to be exported, it's generally best that it lives in its own file. Now, in larger projects, I would take things one step further and give every component its own directory. If you name the file index, then you can easily export it from that directory. But inside the directory, you can add other files like a CSS module for Example, or anything else you might need for testing, Storybook, TypeScript, and so on. This is how they do things by default in Angular, and I find it works really well for large projects. Now, there is one drawback when naming your component index, and that's the fact that it's kind of confusing when working with tabs in your IDE. What you can do is give your component file a regular a name, then use the index file to export it. That's called a barrel, and it will keep your imports nice and concise while also providing a readable file name for the IDE. One of the biggest problems with Big complex apps though, is that they're big. And what that means is that when you ship your app to production, it'll have a slow initial page load because it takes a long time The browser to download the JavaScript bundle. So what can we do about that? If you're using a tool like Next. Js or create react app, which are built on top of webpack, it's very easy to Implement code splitting. Normally, to import code, you use an import statement. However, browsers now support dynamic imports, which allows you to load a module asynchronously using the import function. When webpack sees that code, it automatically knows to split that code into a different bundle, which won't be required until after the initial page load. That works fine for plain JavaScript, but not so much when it comes to React components. However, React has a feature to support lazy loading, which is still experimental today, but it allows you to use dynamic imports on React components. Once a component is dynamically imported, you can then wrap it in the suspense component to show a fallback UI when it's loading. It. Now, another problem you might run into with big projects is that you might have one component at the very top that holds your state, but then you have a deeply nested component that also needs to use that state. What you have to do is then pass that state as a prop to a bunch of intermediate components that don't actually need it until it finally gets to that child. This is known as prop drilling because it makes you want to drill a whole into your brain. One solution is to bring in a state management library like Redux, but that's a heavy handed approach. When you have global data that's used everywhere, like an authenticated user for example, you can share it everywhere with the context API. You first provide the data at a certain point in the component tree, then any component nested under it at any level can and access that data. Sounds awesome, but it does come at a cost. The context API is something that you should use sparingly because it makes your components impossible to reuse without having that provider or as a parent. Most apps only have a handful of values that are truly global. That stuff can go into context while everything else should be more localized. Prop drilling is a vertical problem, but you might also end up with a horizontal problem called prop plowing, which is a term I just made up. What might happen is that you end up with components that have a lot out of different props, and you end up with this long repetitive code where each prop has the same name as the variable passed to it. When you have an object that contains all the props that you're passing to the child, You can use the spread syntax to pass them all at the same time. That makes your code much more concise, and personally, I'm a big fan of this. However, It does make your code less explicit, so I typically only recommend using it when you have a component with a ton of props that really justifies its use. Another area where your React code can get pretty messy is with Event handlers in JSX. What happens is you might have a function that takes the event as its first argument, but one or more other values as secondary arguments. That means to call it, You'll need to break out an arrow function and this can get pretty messy if used in multiple places. A cool little JavaScript trick here is to create a curried function. It. Basically, it's just a function that returns another function. The outer function takes our custom arguments, while the inner function handles the event that's passed by default. This Eliminates the need to define an arrow function for each event. Not only does that make your code look a lot cleaner, but it also gives you a legitimate use case for occurring, which will impress your friends and family. And that brings us to anti pattern number 10. When working with the useState hook in a component, it's tempting to put all of your data in a single object. It. It makes the code look cleaner and may also seem more performant because you only need to call set state once. However, what you should know is that React 18 will do automatic batching whenever you update the state. That means calling setState multiple times in the same function will not trigger multiple re renders. Therefore, it's not a big deal for performance, but more importantly, it makes your code difficult to extract into a custom hook. In the olden days with React class components, it was common to organize your code into smart components and dumb components, where the smart components control the data and the dumb components just render UI with props. There's nothing wrong with this pattern, but nowadays it's It's easier to just extract your logic into a custom hook. What I like to do is build my component with a bunch of different stateful values at first, Then if things get too complex, or I want to use that code in a different component, I extract it into my own custom hook, which itself is just a JavaScript function. It. This allows you to treat virtually all your components as dumb components, while your custom hooks handle the more complex business logic. And with that, we've looked at a small preview of the different things you can screw up in React. Check out my full course if you wanna learn more about React, and here's a special discount for making it all the way to the end of this video. Thanks for watching, and I will see you in the next one.
React
react
JS
js
is
is
elegant
elegant
and
and
minimal
minimal
on
on
the
the
surface.
surface
Just
just
write
write
a
a
JavaScript
javascript
function
function
to
to
represent
represent
a
a
component
component
that
that
automatically
automatically
renders
renders
when
when
your
your
data
data
changes.
changes
It's
it's
simple,
simple
but
but
also
also
misleading.
misleading
In
in
reality,
reality
React
react
is
is
a
a
highly
highly
complex
complex
UI
ui
library
library
with
with
a
a
good
good
amount
amount
of
of
technical
technical
baggage
baggage
that
that
has
has
accumulated
accumulated
over
over
the
the
last
last
a
a
decade.
decade
Many
many
newer
newer
frameworks
frameworks
attempt
attempt
to
to
do
do
things
things
better,
better
but
but
React
react
is
is
still
still
the
the
king.
king
And
and
if
if
you
you
wanna
wanna
be
be
a
a
web
web
developer
developer
in
in
2022,
2022
it's
it's
a
a
very
very
good
good
idea
idea
to
to
learn
learn
it.
it
The
the
problem
problem
is
is
that
that
React
react
is
is
unopinionated
unopinionated
yet
yet
provides
provides
many
many
different
different
ways
ways
to
to
solve
solve
the
the
same
same
problems.
problems
That
that
leaves
leaves
us
us
developers
developers
with
with
plenty
plenty
of
of
room
room
to
to
screw
screw
things
things
up
up
with
with
our
our
own
own
stupid
stupid
ideas.
ideas
In
in
today's
today's
episode
episode
out
out
of
of
code
code
this,
this
not
not
that.
that
We'll
we'll
look
look
at
at
10
10
anti
anti
patterns
patterns
in
in
React,
react
along
along
with
with
tips
tips
and
and
tricks
tricks
to
to
improve
improve
our
our
code,
code
and
and
also
also
prepare
prepare
for
for
a
a
front
front
end
end
technical
technical
interview.
interview
Before
before
we
we
get
get
started,
started
I
i
have
have
an
an
announcement.
announcement
I'm
i'm
working
working
on
on
a
a
brand
brand
new
new
course
course
for
for
pro
pro
members
members
that
that
teaches
teaches
the
the
fundamentals
fundamentals
of
of
React
react
in
in
my
my
100
100
seconds
seconds
of
of
code
code
format,
format
then
then
puts
puts
those
those
concepts
concepts
to
to
use
use
by
by
building
building
multiple
multiple
full
full
stack
stack
applications
applications
in
in
scratch.
scratch
The
the
course
course
is
is
not
not
finished
finished
yet,
yet
but
but
I'll
i'll
be
be
releasing
releasing
new
new
videos
videos
for
for
it
it
every
every
couple
couple
days
days
on
on
FireShip
fireship
IO.
io
When
when
I
i
initially
initially
start
start
building
building
a
a
React
react
app,
app
I
i
usually
usually
start
start
by
by
writing
writing
1
1
big
big
giant
giant
any
any
component,
component
often
often
in
in
the
the
app
app
component
component
provided
provided
by
by
create
create
react
react
app.
app
And
and
that's
that's
intentional
intentional
because
because
I
i
usually
usually
don't
don't
know
know
how
how
I
i
want
want
my
my
code
code
to
to
be
be
organized
organized
initially
initially
and
and
I
i
don't
don't
want
want
to
to
waste
waste
my
my
time
time
over
over
organizing
organizing
things
things
before
before
I
i
even
even
know
know
what
what
I
i
wanna
wanna
do.
do
However,
however
this
this
results
results
in
in
an
an
anti
anti
pattern
pattern
of
of
having
having
one
one
overly
overly
large
large
deeply
deeply
nested
nested
component.
component
A
a
component
component
like
like
this
this
is
is
hard
hard
to
to
understand,
understand
re
re
Factor
factor
and
and
test.
test
We
we
can
can
improve
improve
this
this
code
code
by
by
refactoring
refactoring
into
into
reusable
reusable
components,
components
like
like
this
this
navbar
navbar
could
could
easily
easily
be
be
broken
broken
down
down
into
into
1
1
or
or
or
or
components
components
that
that
better
better
represent
represent
what
what
it
it
does.
does
Now
now
that
that
may
may
sound
sound
like
like
a
a
lot
lot
of
of
work,
work
but
but
luckily,
luckily
there's
there's
a
a
Versus
versus
code
code
extension
extension
called
called
glean
glean
that
that
can
can
leverage
leverage
the
the
IDE
ide
to
to
do
do
this
this
work
work
for
for
us.
us
Install
install
it,
it
then
then
highlight
highlight
the
the
code
code
you
you
want
want
to
to
extract
extract
into
into
its
its
own
own
component,
component
click
click
the
the
light
light
bulb,
bulb
and
and
you'll
you'll
see
see
a
a
bunch
bunch
of
of
options
options
to
to
refactor
refactor
like
like
render
render
conditionally
conditionally
it
it
or
or
extract
extract
component.
component
Give
give
it
it
a
a
name,
name
then
then
it
it
will
will
automatically
automatically
move
move
the
the
code
code
while
while
including
including
the
the
required
required
props.
props
It's
it's
a
a
massive
massive
time
time
saver
saver
that
that
I
i
couldn't
couldn't
imagine
imagine
and
and
without.
without
Now,
now
when
when
you
you
start
start
refactoring
refactoring
a
a
large
large
component,
component
you
you
might
might
be
be
tempted
tempted
into
into
another
another
anti
anti
pattern
pattern
of
of
nesting
nesting
components.
components
In
in
this
this
example,
example
we've
we've
defined
defined
a
a
child
child
component
component
that
that
lives
lives
inside
inside
the
the
parent
parent
component.
component
The
the
child
child
uses
uses
a
a
function
function
defined
defined
in
in
the
the
parent
parent
and
and
by
by
defining
defining
it
it
here,
here
we
we
don't
don't
need
need
to
to
provide
provide
a
a
prop
prop
for
for
that
that
function.
function
It
it
feels
feels
very
very
intuitive
intuitive
and
and
it
it
works
works
perfectly
perfectly
fine.
fine
But
but
there's
there's
a
a
major
major
problem
problem
here.
here
Every
every
time
time
the
the
parent
parent
component
component
is
is
rendered,
rendered
it
it
will
will
also
also
redefine
redefine
the
the
child
child
component,
component
which
which
means
means
it
it
gets
gets
a
a
new
new
memory
memory
address
address
and
and
that
that
could
could
lead
lead
to
to
performance
performance
issues
issues
and
and
unpredictable
unpredictable
behavior.
behavior
The
the
solution
solution
is
is
to
to
either
either
not
not
define
define
a
a
child
child
component
component
at
at
all
all
or
or
to
to
move
move
the
the
child
child
component
component
out
out
of
of
the
the
parent
parent
and
and
pass
pass
the
the
function
function
in
in
as
as
a
a
prop.
prop
This
this
example
example
demonstrates
demonstrates
how
how
react
react
is
is
very
very
simple
simple
on
on
the
the
surface,
surface
but
but
if
if
you
you
don't
don't
know
know
exactly
exactly
what's
what's
going
going
on,
on
it's
it's
easy
easy
to
to
shoot
shoot
yourself
yourself
in
in
but
but
here's
here's
a
a
similar
similar
example
example
of
of
a
a
component
component
that
that
does
does
too
too
much
much
work
work
and
and
might
might
end
end
up
up
causing
causing
performance
performance
issues.
issues
Let's
let's
imagine
imagine
we
we
have
have
a
a
component
component
with
with
2
2
different
different
pieces
pieces
of
of
state.
state
On
on
one
one
piece
piece
of
of
date,
date
we
we
need
need
to
to
run
run
an
an
expensive
expensive
calculation
calculation
anytime
anytime
the
the
value
value
changes.
changes
The
the
problem
problem
with
with
our
our
current
current
implementation
implementation
is
is
that
that
anytime
anytime
the
the
state
state
changes
changes
on
on
this
this
component,
component
It
it
will
will
rerun
rerun
the
the
expensive
expensive
calculation
calculation
even
even
though
though
it
it
only
only
depends
depends
on
on
the
the
one
one
count
count
value.
value
It's
it's
not
not
very
very
obvious,
obvious
but
but
you
you
have
have
a
a
potential
potential
performance
performance
bottleneck
bottleneck
air.
air
In
in
a
a
situation
situation
like
like
this,
this
you'll
you'll
want
want
to
to
use
use
the
the
use
use
memo
memo
hook.
hook
What
what
it
it
will
will
do
do
is
is
remember
remember
the
the
last
last
value
value
and
and
only
only
run
run
the
the
actual
actual
and
and
when
when
it's
it's
dependent
dependent
data
data
changes.
changes
You
you
might
might
also
also
run
run
into
into
the
the
situation
situation
when
when
working
working
with
with
functions,
functions
and
and
for
for
that,
that
React
react
provides
provides
a
a
useCallback
usecallback
hook.
hook
Now
now
another
another
thing
thing
you
you
might
might
run
run
into
into
is
is
that
that
when
when
defining
defining
a
a
brand
brand
new
new
component,
component
you
you
get
get
an
an
error
error
when
when
trying
trying
to
to
return
return
2
2
sibling
sibling
elements
elements
together.
together
That's
that's
because
because
every
every
component
component
can
can
have
have
only
only
one
one
root
root
element.
element
So
so
what
what
you
you
might
might
do
do
is
is
wrap
wrap
it
it
with
with
a
a
div.
div
That
that
works
works
perfectly
perfectly
fine,
fine
but
but
it
it
leads
leads
to
to
a
a
bunch
bunch
of
of
unnecessary
unnecessary
divs
divs
in
in
in
in
markup,
markup
and
and
that
that
can
can
cause
cause
issues
issues
with
with
accessibility
accessibility
and
and
CSS
css
styling.
styling
To
to
address
address
this
this
concern,
concern
React
react
has
has
a
a
built
built
in
in
fragment
fragment
component,
component
or
or
better
better
yet,
yet
You
you
can
can
use
use
the
the
shorthand
shorthand
syntax
syntax
of
of
an
an
empty
empty
element,
element
which
which
tells
tells
React
react
to
to
render
render
nothing
nothing
as
as
the
the
parent
parent
element.
element
Now,
now
as
as
your
your
app
app
grows
grows
in
in
complexity
complexity
and
and
you
you
start
start
creating
creating
more
more
and
and
more
more
components,
components
You'll
you'll
want
want
to
to
have
have
an
an
opinionated
opinionated
way
way
to
to
organize
organize
them.
them
A
a
good
good
rule
rule
to
to
follow
follow
is
is
1
1
component
component
per
per
file.
file
It
it
can
can
be
be
tempting
tempting
to
to
export
export
multiple
multiple
components
components
from
from
a
a
single
single
a
a
file,
file
but
but
things
things
will
will
get
get
pretty
pretty
complicated
complicated
quickly.
quickly
If
if
a
a
component
component
is
is
going
going
to
to
be
be
exported,
exported
it's
it's
generally
generally
best
best
that
that
it
it
lives
lives
in
in
its
its
own
own
file.
file
Now,
now
in
in
larger
larger
projects,
projects
I
i
would
would
take
take
things
things
one
one
step
step
further
further
and
and
give
give
every
every
component
component
its
its
own
own
directory.
directory
If
if
you
you
name
name
the
the
file
file
index,
index
then
then
you
you
can
can
easily
easily
export
export
it
it
from
from
that
that
directory.
directory
But
but
inside
inside
the
the
directory,
directory
you
you
can
can
add
add
other
other
files
files
like
like
a
a
CSS
css
module
module
for
for
Example,
example
or
or
anything
anything
else
else
you
you
might
might
need
need
for
for
testing,
testing
Storybook,
storybook
TypeScript,
typescript
and
and
so
so
on.
on
This
this
is
is
how
how
they
they
do
do
things
things
by
by
default
default
in
in
Angular,
angular
and
and
I
i
find
find
it
it
works
works
really
really
well
well
for
for
large
large
projects.
projects
Now,
now
there
there
is
is
one
one
drawback
drawback
when
when
naming
naming
your
your
component
component
index,
index
and
and
that's
that's
the
the
fact
fact
that
that
it's
it's
kind
kind
of
of
confusing
confusing
when
when
working
working
with
with
tabs
tabs
in
in
your
your
IDE.
ide
What
what
you
you
can
can
do
do
is
is
give
give
your
your
component
component
file
file
a
a
regular
regular
a
a
name,
name
then
then
use
use
the
the
index
index
file
file
to
to
export
export
it.
it
That's
that's
called
called
a
a
barrel,
barrel
and
and
it
it
will
will
keep
keep
your
your
imports
imports
nice
nice
and
and
concise
concise
while
while
also
also
providing
providing
a
a
readable
readable
file
file
name
name
for
for
the
the
IDE.
ide
One
one
of
of
the
the
biggest
biggest
problems
problems
with
with
Big
big
complex
complex
apps
apps
though,
though
is
is
that
that
they're
they're
big.
big
And
and
what
what
that
that
means
means
is
is
that
that
when
when
you
you
ship
ship
your
your
app
app
to
to
production,
production
it'll
it'll
have
have
a
a
slow
slow
initial
initial
page
page
load
load
because
because
it
it
takes
takes
a
a
long
long
time
time
The
the
browser
browser
to
to
download
download
the
the
JavaScript
javascript
bundle.
bundle
So
so
what
what
can
can
we
we
do
do
about
about
that?
that
If
if
you're
you're
using
using
a
a
tool
tool
like
like
Next.
next
Js
js
or
or
create
create
react
react
app,
app
which
which
are
are
built
built
on
on
top
top
of
of
webpack,
webpack
it's
it's
very
very
easy
easy
to
to
Implement
implement
code
code
splitting.
splitting
Normally,
normally
to
to
import
import
code,
code
you
you
use
use
an
an
import
import
statement.
statement
However,
however
browsers
browsers
now
now
support
support
dynamic
dynamic
imports,
imports
which
which
allows
allows
you
you
to
to
load
load
a
a
module
module
asynchronously
asynchronously
using
using
the
the
import
import
function.
function
When
when
webpack
webpack
sees
sees
that
that
code,
code
it
it
automatically
automatically
knows
knows
to
to
split
split
that
that
code
code
into
into
a
a
different
different
bundle,
bundle
which
which
won't
won't
be
be
required
required
until
until
after
after
the
the
initial
initial
page
page
load.
load
That
that
works
works
fine
fine
for
for
plain
plain
JavaScript,
javascript
but
but
not
not
so
so
much
much
when
when
it
it
comes
comes
to
to
React
react
components.
components
However,
however
React
react
has
has
a
a
feature
feature
to
to
support
support
lazy
lazy
loading,
loading
which
which
is
is
still
still
experimental
experimental
today,
today
but
but
it
it
allows
allows
you
you
to
to
use
use
dynamic
dynamic
imports
imports
on
on
React
react
components.
components
Once
once
a
a
component
component
is
is
dynamically
dynamically
imported,
imported
you
you
can
can
then
then
wrap
wrap
it
it
in
in
the
the
suspense
suspense
component
component
to
to
show
show
a
a
fallback
fallback
UI
ui
when
when
it's
it's
loading.
loading
It.
it
Now,
now
another
another
problem
problem
you
you
might
might
run
run
into
into
with
with
big
big
projects
projects
is
is
that
that
you
you
might
might
have
have
one
one
component
component
at
at
the
the
very
very
top
top
that
that
holds
holds
your
your
state,
state
but
but
then
then
you
you
have
have
a
a
deeply
deeply
nested
nested
component
component
that
that
also
also
needs
needs
to
to
use
use
that
that
state.
state
What
what
you
you
have
have
to
to
do
do
is
is
then
then
pass
pass
that
that
state
state
as
as
a
a
prop
prop
to
to
a
a
bunch
bunch
of
of
intermediate
intermediate
components
components
that
that
don't
don't
actually
actually
need
need
it
it
until
until
it
it
finally
finally
gets
gets
to
to
that
that
child.
child
This
this
is
is
known
known
as
as
prop
prop
drilling
drilling
because
because
it
it
makes
makes
you
you
want
want
to
to
drill
drill
a
a
whole
whole
into
into
your
your
brain.
brain
One
one
solution
solution
is
is
to
to
bring
bring
in
in
a
a
state
state
management
management
library
library
like
like
Redux,
redux
but
but
that's
that's
a
a
heavy
heavy
handed
handed
approach.
approach
When
when
you
you
have
have
global
global
data
data
that's
that's
used
used
everywhere,
everywhere
like
like
an
an
authenticated
authenticated
user
user
for
for
example,
example
you
you
can
can
share
share
it
it
everywhere
everywhere
with
with
the
the
context
context
API.
api
You
you
first
first
provide
provide
the
the
data
data
at
at
a
a
certain
certain
point
point
in
in
the
the
component
component
tree,
tree
then
then
any
any
component
component
nested
nested
under
under
it
it
at
at
any
any
level
level
can
can
and
and
access
access
that
that
data.
data
Sounds
sounds
awesome,
awesome
but
but
it
it
does
does
come
come
at
at
a
a
cost.
cost
The
the
context
context
API
api
is
is
something
something
that
that
you
you
should
should
use
use
sparingly
sparingly
because
because
it
it
makes
makes
your
your
components
components
impossible
impossible
to
to
reuse
reuse
without
without
having
having
that
that
provider
provider
or
or
as
as
a
a
parent.
parent
Most
most
apps
apps
only
only
have
have
a
a
handful
handful
of
of
values
values
that
that
are
are
truly
truly
global.
global
That
that
stuff
stuff
can
can
go
go
into
into
context
context
while
while
everything
everything
else
else
should
should
be
be
more
more
localized.
localized
Prop
prop
drilling
drilling
is
is
a
a
vertical
vertical
problem,
problem
but
but
you
you
might
might
also
also
end
end
up
up
with
with
a
a
horizontal
horizontal
problem
problem
called
called
prop
prop
plowing,
plowing
which
which
is
is
a
a
term
term
I
i
just
just
made
made
up.
up
What
what
might
might
happen
happen
is
is
that
that
you
you
end
end
up
up
with
with
components
components
that
that
have
have
a
a
lot
lot
out
out
of
of
different
different
props,
props
and
and
you
you
end
end
up
up
with
with
this
this
long
long
repetitive
repetitive
code
code
where
where
each
each
prop
prop
has
has
the
the
same
same
name
name
as
as
the
the
variable
variable
passed
passed
to
to
it.
it
When
when
you
you
have
have
an
an
object
object
that
that
contains
contains
all
all
the
the
props
props
that
that
you're
you're
passing
passing
to
to
the
the
child,
child
You
you
can
can
use
use
the
the
spread
spread
syntax
syntax
to
to
pass
pass
them
them
all
all
at
at
the
the
same
same
time.
time
That
that
makes
makes
your
your
code
code
much
much
more
more
concise,
concise
and
and
personally,
personally
I'm
i'm
a
a
big
big
fan
fan
of
of
this.
this
However,
however
It
it
does
does
make
make
your
your
code
code
less
less
explicit,
explicit
so
so
I
i
typically
typically
only
only
recommend
recommend
using
using
it
it
when
when
you
you
have
have
a
a
component
component
with
with
a
a
ton
ton
of
of
props
props
that
that
really
really
justifies
justifies
its
its
use.
use
Another
another
area
area
where
where
your
your
React
react
code
code
can
can
get
get
pretty
pretty
messy
messy
is
is
with
with
Event
event
handlers
handlers
in
in
JSX.
jsx
What
what
happens
happens
is
is
you
you
might
might
have
have
a
a
function
function
that
that
takes
takes
the
the
event
event
as
as
its
its
first
first
argument,
argument
but
but
one
one
or
or
more
more
other
other
values
values
as
as
secondary
secondary
arguments.
arguments
That
that
means
means
to
to
call
call
it,
it
You'll
you'll
need
need
to
to
break
break
out
out
an
an
arrow
arrow
function
function
and
and
this
this
can
can
get
get
pretty
pretty
messy
messy
if
if
used
used
in
in
multiple
multiple
places.
places
A
a
cool
cool
little
little
JavaScript
javascript
trick
trick
here
here
is
is
to
to
create
create
a
a
curried
curried
function.
function
It.
it
Basically,
basically
it's
it's
just
just
a
a
function
function
that
that
returns
returns
another
another
function.
function
The
the
outer
outer
function
function
takes
takes
our
our
custom
custom
arguments,
arguments
while
while
the
the
inner
inner
function
function
handles
handles
the
the
event
event
that's
that's
passed
passed
by
by
default.
default
This
this
Eliminates
eliminates
the
the
need
need
to
to
define
define
an
an
arrow
arrow
function
function
for
for
each
each
event.
event
Not
not
only
only
does
does
that
that
make
make
your
your
code
code
look
look
a
a
lot
lot
cleaner,
cleaner
but
but
it
it
also
also
gives
gives
you
you
a
a
legitimate
legitimate
use
use
case
case
for
for
occurring,
occurring
which
which
will
will
impress
impress
your
your
friends
friends
and
and
family.
family
And
and
that
that
brings
brings
us
us
to
to
anti
anti
pattern
pattern
number
number
10.
10
When
when
working
working
with
with
the
the
useState
usestate
hook
hook
in
in
a
a
component,
component
it's
it's
tempting
tempting
to
to
put
put
all
all
of
of
your
your
data
data
in
in
a
a
single
single
object.
object
It.
it
It
it
makes
makes
the
the
code
code
look
look
cleaner
cleaner
and
and
may
may
also
also
seem
seem
more
more
performant
performant
because
because
you
you
only
only
need
need
to
to
call
call
set
set
state
state
once.
once
However,
however
what
what
you
you
should
should
know
know
is
is
that
that
React
react
18
18
will
will
do
do
automatic
automatic
batching
batching
whenever
whenever
you
you
update
update
the
the
state.
state
That
that
means
means
calling
calling
setState
setstate
multiple
multiple
times
times
in
in
the
the
same
same
function
function
will
will
not
not
trigger
trigger
multiple
multiple
re
re
renders.
renders
Therefore,
therefore
it's
it's
not
not
a
a
big
big
deal
deal
for
for
performance,
performance
but
but
more
more
importantly,
importantly
it
it
makes
makes
your
your
code
code
difficult
difficult
to
to
extract
extract
into
into
a
a
custom
custom
hook.
hook
In
in
the
the
olden
olden
days
days
with
with
React
react
class
class
components,
components
it
it
was
was
common
common
to
to
organize
organize
your
your
code
code
into
into
smart
smart
components
components
and
and
dumb
dumb
components,
components
where
where
the
the
smart
smart
components
components
control
control
the
the
data
data
and
and
the
the
dumb
dumb
components
components
just
just
render
render
UI
ui
with
with
props.
props
There's
there's
nothing
nothing
wrong
wrong
with
with
this
this
pattern,
pattern
but
but
nowadays
nowadays
it's
it's
It's
it's
easier
easier
to
to
just
just
extract
extract
your
your
logic
logic
into
into
a
a
custom
custom
hook.
hook
What
what
I
i
like
like
to
to
do
do
is
is
build
build
my
my
component
component
with
with
a
a
bunch
bunch
of
of
different
different
stateful
stateful
values
values
at
at
first,
first
Then
then
if
if
things
things
get
get
too
too
complex,
complex
or
or
I
i
want
want
to
to
use
use
that
that
code
code
in
in
a
a
different
different
component,
component
I
i
extract
extract
it
it
into
into
my
my
own
own
custom
custom
hook,
hook
which
which
itself
itself
is
is
just
just
a
a
JavaScript
javascript
function.
function
It.
it
This
this
allows
allows
you
you
to
to
treat
treat
virtually
virtually
all
all
your
your
components
components
as
as
dumb
dumb
components,
components
while
while
your
your
custom
custom
hooks
hooks
handle
handle
the
the
more
more
complex
complex
business
business
logic.
logic
And
and
with
with
that,
that
we've
we've
looked
looked
at
at
a
a
small
small
preview
preview
of
of
the
the
different
different
things
things
you
you
can
can
screw
screw
up
up
in
in
React.
react
Check
check
out
out
my
my
full
full
course
course
if
if
you
you
wanna
wanna
learn
learn
more
more
about
about
React,
react
and
and
here's
here's
a
a
special
special
discount
discount
for
for
making
making
it
it
all
all
the
the
way
way
to
to
the
the
end
end
of
of
this
this
video.
video
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The speakers discuss the benefits of React as a low-cost, low-pressure language, but acknowledge that it is still the king of the UI language. They also give advice on improving code organization and recommend using a tool like Redux to avoid building unnecessary code. Additionally, they explain how to extract logic from a custom hook in React and offer a discount for making it all the way to the end of the video.
10 React Antipatterns to Avoid - Code This, Not That!
React JS is elegant and minimal on the surface. Just write a JavaScript function to represent a component that automatically renders when your data changes. It's simple, but also misleading. In reality, React is a highly complex UI library with a good amount of technical baggage that has accumulated over the last a decade. Many newer frameworks attempt to do things better, but React is still the king. And if you wanna be a web developer in 2022, it's a very good idea to learn it. The problem is that React is unopinionated yet provides many different ways to solve the same problems. That leaves us developers with plenty of room to screw things up with our own stupid ideas. In today's episode out of code this, not that. We'll look at 10 anti patterns in React, along with tips and tricks to improve our code, and also prepare for a front end technical interview. Before we get started, I have an announcement. I'm working on a brand new course for pro members that teaches the fundamentals of React in my 100 seconds of code format, then puts those concepts to use by building multiple full stack applications in scratch. The course is not finished yet, but I'll be releasing new videos for it every couple days on FireShip IO. When I initially start building a React app, I usually start by writing 1 big giant any component, often in the app component provided by create react app. And that's intentional because I usually don't know how I want my code to be organized initially and I don't want to waste my time over organizing things before I even know what I wanna do. However, this results in an anti pattern of having one overly large deeply nested component. A component like this is hard to understand, re Factor and test. We can improve this code by refactoring into reusable components, like this navbar could easily be broken down into 1 or or components that better represent what it does. Now that may sound like a lot of work, but luckily, there's a Versus code extension called glean that can leverage the IDE to do this work for us. Install it, then highlight the code you want to extract into its own component, click the light bulb, and you'll see a bunch of options to refactor like render conditionally it or extract component. Give it a name, then it will automatically move the code while including the required props. It's a massive time saver that I couldn't imagine and without. Now, when you start refactoring a large component, you might be tempted into another anti pattern of nesting components. In this example, we've defined a child component that lives inside the parent component. The child uses a function defined in the parent and by defining it here, we don't need to provide a prop for that function. It feels very intuitive and it works perfectly fine. But there's a major problem here. Every time the parent component is rendered, it will also redefine the child component, which means it gets a new memory address and that could lead to performance issues and unpredictable behavior. The solution is to either not define a child component at all or to move the child component out of the parent and pass the function in as a prop. This example demonstrates how react is very simple on the surface, but if you don't know exactly what's going on, it's easy to shoot yourself in but here's a similar example of a component that does too much work and might end up causing performance issues. Let's imagine we have a component with 2 different pieces of state. On one piece of date, we need to run an expensive calculation anytime the value changes. The problem with our current implementation is that anytime the state changes on this component, It will rerun the expensive calculation even though it only depends on the one count value. It's not very obvious, but you have a potential performance bottleneck air. In a situation like this, you'll want to use the use memo hook. What it will do is remember the last value and only run the actual and when it's dependent data changes. You might also run into the situation when working with functions, and for that, React provides a useCallback hook. Now another thing you might run into is that when defining a brand new component, you get an error when trying to return 2 sibling elements together. That's because every component can have only one root element. So what you might do is wrap it with a div. That works perfectly fine, but it leads to a bunch of unnecessary divs in in markup, and that can cause issues with accessibility and CSS styling. To address this concern, React has a built in fragment component, or better yet, You can use the shorthand syntax of an empty element, which tells React to render nothing as the parent element. Now, as your app grows in complexity and you start creating more and more components, You'll want to have an opinionated way to organize them. A good rule to follow is 1 component per file. It can be tempting to export multiple components from a single a file, but things will get pretty complicated quickly. If a component is going to be exported, it's generally best that it lives in its own file. Now, in larger projects, I would take things one step further and give every component its own directory. If you name the file index, then you can easily export it from that directory. But inside the directory, you can add other files like a CSS module for Example, or anything else you might need for testing, Storybook, TypeScript, and so on. This is how they do things by default in Angular, and I find it works really well for large projects. Now, there is one drawback when naming your component index, and that's the fact that it's kind of confusing when working with tabs in your IDE. What you can do is give your component file a regular a name, then use the index file to export it. That's called a barrel, and it will keep your imports nice and concise while also providing a readable file name for the IDE. One of the biggest problems with Big complex apps though, is that they're big. And what that means is that when you ship your app to production, it'll have a slow initial page load because it takes a long time The browser to download the JavaScript bundle. So what can we do about that? If you're using a tool like Next. Js or create react app, which are built on top of webpack, it's very easy to Implement code splitting. Normally, to import code, you use an import statement. However, browsers now support dynamic imports, which allows you to load a module asynchronously using the import function. When webpack sees that code, it automatically knows to split that code into a different bundle, which won't be required until after the initial page load. That works fine for plain JavaScript, but not so much when it comes to React components. However, React has a feature to support lazy loading, which is still experimental today, but it allows you to use dynamic imports on React components. Once a component is dynamically imported, you can then wrap it in the suspense component to show a fallback UI when it's loading. It. Now, another problem you might run into with big projects is that you might have one component at the very top that holds your state, but then you have a deeply nested component that also needs to use that state. What you have to do is then pass that state as a prop to a bunch of intermediate components that don't actually need it until it finally gets to that child. This is known as prop drilling because it makes you want to drill a whole into your brain. One solution is to bring in a state management library like Redux, but that's a heavy handed approach. When you have global data that's used everywhere, like an authenticated user for example, you can share it everywhere with the context API. You first provide the data at a certain point in the component tree, then any component nested under it at any level can and access that data. Sounds awesome, but it does come at a cost. The context API is something that you should use sparingly because it makes your components impossible to reuse without having that provider or as a parent. Most apps only have a handful of values that are truly global. That stuff can go into context while everything else should be more localized. Prop drilling is a vertical problem, but you might also end up with a horizontal problem called prop plowing, which is a term I just made up. What might happen is that you end up with components that have a lot out of different props, and you end up with this long repetitive code where each prop has the same name as the variable passed to it. When you have an object that contains all the props that you're passing to the child, You can use the spread syntax to pass them all at the same time. That makes your code much more concise, and personally, I'm a big fan of this. However, It does make your code less explicit, so I typically only recommend using it when you have a component with a ton of props that really justifies its use. Another area where your React code can get pretty messy is with Event handlers in JSX. What happens is you might have a function that takes the event as its first argument, but one or more other values as secondary arguments. That means to call it, You'll need to break out an arrow function and this can get pretty messy if used in multiple places. A cool little JavaScript trick here is to create a curried function. It. Basically, it's just a function that returns another function. The outer function takes our custom arguments, while the inner function handles the event that's passed by default. This Eliminates the need to define an arrow function for each event. Not only does that make your code look a lot cleaner, but it also gives you a legitimate use case for occurring, which will impress your friends and family. And that brings us to anti pattern number 10. When working with the useState hook in a component, it's tempting to put all of your data in a single object. It. It makes the code look cleaner and may also seem more performant because you only need to call set state once. However, what you should know is that React 18 will do automatic batching whenever you update the state. That means calling setState multiple times in the same function will not trigger multiple re renders. Therefore, it's not a big deal for performance, but more importantly, it makes your code difficult to extract into a custom hook. In the olden days with React class components, it was common to organize your code into smart components and dumb components, where the smart components control the data and the dumb components just render UI with props. There's nothing wrong with this pattern, but nowadays it's It's easier to just extract your logic into a custom hook. What I like to do is build my component with a bunch of different stateful values at first, Then if things get too complex, or I want to use that code in a different component, I extract it into my own custom hook, which itself is just a JavaScript function. It. This allows you to treat virtually all your components as dumb components, while your custom hooks handle the more complex business logic. And with that, we've looked at a small preview of the different things you can screw up in React. Check out my full course if you wanna learn more about React, and here's a special discount for making it all the way to the end of this video. Thanks for watching, and I will see you in the next one.
The speakers discuss the benefits of React as a low-cost, low-pressure language, but acknowledge that it is still the king of the UI language. They also give advice on improving code organization and recommend using a tool like Redux to avoid building unnecessary code. Additionally, they explain how to extract logic from a custom hook in React and offer a discount for making it all the way to the end of the video.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : 10 React Antipatterns to Avoid - Code This, Not That! 
        and a small summary : The speakers discuss the benefits of React as a low-cost, low-pressure language, but acknowledge that it is still the king of the UI language. They also give advice on improving code organization and recommend using a tool like Redux to avoid building unnecessary code. Additionally, they explain how to extract logic from a custom hook in React and offer a discount for making it all the way to the end of the video.
        [/INST]
        
        Generate the video : React JS is elegant and minimal on the surface. Just write a JavaScript function to represent a component that automatically renders when your data changes. It's simple, but also misleading. In reality, React is a highly complex UI library with a good amount of technical baggage that has accumulated over the last a decade. Many newer frameworks attempt to do things better, but React is still the king. And if you wanna be a web developer in 2022, it's a very good idea to learn it. The problem is that React is unopinionated yet provides many different ways to solve the same problems. That leaves us developers with plenty of room to screw things up with our own stupid ideas. In today's episode out of code this, not that. We'll look at 10 anti patterns in React, along with tips and tricks to improve our code, and also prepare for a front end technical interview. Before we get started, I have an announcement. I'm working on a brand new course for pro members that teaches the fundamentals of React in my 100 seconds of code format, then puts those concepts to use by building multiple full stack applications in scratch. The course is not finished yet, but I'll be releasing new videos for it every couple days on FireShip IO. When I initially start building a React app, I usually start by writing 1 big giant any component, often in the app component provided by create react app. And that's intentional because I usually don't know how I want my code to be organized initially and I don't want to waste my time over organizing things before I even know what I wanna do. However, this results in an anti pattern of having one overly large deeply nested component. A component like this is hard to understand, re Factor and test. We can improve this code by refactoring into reusable components, like this navbar could easily be broken down into 1 or or components that better represent what it does. Now that may sound like a lot of work, but luckily, there's a Versus code extension called glean that can leverage the IDE to do this work for us. Install it, then highlight the code you want to extract into its own component, click the light bulb, and you'll see a bunch of options to refactor like render conditionally it or extract component. Give it a name, then it will automatically move the code while including the required props. It's a massive time saver that I couldn't imagine and without. Now, when you start refactoring a large component, you might be tempted into another anti pattern of nesting components. In this example, we've defined a child component that lives inside the parent component. The child uses a function defined in the parent and by defining it here, we don't need to provide a prop for that function. It feels very intuitive and it works perfectly fine. But there's a major problem here. Every time the parent component is rendered, it will also redefine the child component, which means it gets a new memory address and that could lead to performance issues and unpredictable behavior. The solution is to either not define a child component at all or to move the child component out of the parent and pass the function in as a prop. This example demonstrates how react is very simple on the surface, but if you don't know exactly what's going on, it's easy to shoot yourself in but here's a similar example of a component that does too much work and might end up causing performance issues. Let's imagine we have a component with 2 different pieces of state. On one piece of date, we need to run an expensive calculation anytime the value changes. The problem with our current implementation is that anytime the state changes on this component, It will rerun the expensive calculation even though it only depends on the one count value. It's not very obvious, but you have a potential performance bottleneck air. In a situation like this, you'll want to use the use memo hook. What it will do is remember the last value and only run the actual and when it's dependent data changes. You might also run into the situation when working with functions, and for that, React provides a useCallback hook. Now another thing you might run into is that when defining a brand new component, you get an error when trying to return 2 sibling elements together. That's because every component can have only one root element. So what you might do is wrap it with a div. That works perfectly fine, but it leads to a bunch of unnecessary divs in in markup, and that can cause issues with accessibility and CSS styling. To address this concern, React has a built in fragment component, or better yet, You can use the shorthand syntax of an empty element, which tells React to render nothing as the parent element. Now, as your app grows in complexity and you start creating more and more components, You'll want to have an opinionated way to organize them. A good rule to follow is 1 component per file. It can be tempting to export multiple components from a single a file, but things will get pretty complicated quickly. If a component is going to be exported, it's generally best that it lives in its own file. Now, in larger projects, I would take things one step further and give every component its own directory. If you name the file index, then you can easily export it from that directory. But inside the directory, you can add other files like a CSS module for Example, or anything else you might need for testing, Storybook, TypeScript, and so on. This is how they do things by default in Angular, and I find it works really well for large projects. Now, there is one drawback when naming your component index, and that's the fact that it's kind of confusing when working with tabs in your IDE. What you can do is give your component file a regular a name, then use the index file to export it. That's called a barrel, and it will keep your imports nice and concise while also providing a readable file name for the IDE. One of the biggest problems with Big complex apps though, is that they're big. And what that means is that when you ship your app to production, it'll have a slow initial page load because it takes a long time The browser to download the JavaScript bundle. So what can we do about that? If you're using a tool like Next. Js or create react app, which are built on top of webpack, it's very easy to Implement code splitting. Normally, to import code, you use an import statement. However, browsers now support dynamic imports, which allows you to load a module asynchronously using the import function. When webpack sees that code, it automatically knows to split that code into a different bundle, which won't be required until after the initial page load. That works fine for plain JavaScript, but not so much when it comes to React components. However, React has a feature to support lazy loading, which is still experimental today, but it allows you to use dynamic imports on React components. Once a component is dynamically imported, you can then wrap it in the suspense component to show a fallback UI when it's loading. It. Now, another problem you might run into with big projects is that you might have one component at the very top that holds your state, but then you have a deeply nested component that also needs to use that state. What you have to do is then pass that state as a prop to a bunch of intermediate components that don't actually need it until it finally gets to that child. This is known as prop drilling because it makes you want to drill a whole into your brain. One solution is to bring in a state management library like Redux, but that's a heavy handed approach. When you have global data that's used everywhere, like an authenticated user for example, you can share it everywhere with the context API. You first provide the data at a certain point in the component tree, then any component nested under it at any level can and access that data. Sounds awesome, but it does come at a cost. The context API is something that you should use sparingly because it makes your components impossible to reuse without having that provider or as a parent. Most apps only have a handful of values that are truly global. That stuff can go into context while everything else should be more localized. Prop drilling is a vertical problem, but you might also end up with a horizontal problem called prop plowing, which is a term I just made up. What might happen is that you end up with components that have a lot out of different props, and you end up with this long repetitive code where each prop has the same name as the variable passed to it. When you have an object that contains all the props that you're passing to the child, You can use the spread syntax to pass them all at the same time. That makes your code much more concise, and personally, I'm a big fan of this. However, It does make your code less explicit, so I typically only recommend using it when you have a component with a ton of props that really justifies its use. Another area where your React code can get pretty messy is with Event handlers in JSX. What happens is you might have a function that takes the event as its first argument, but one or more other values as secondary arguments. That means to call it, You'll need to break out an arrow function and this can get pretty messy if used in multiple places. A cool little JavaScript trick here is to create a curried function. It. Basically, it's just a function that returns another function. The outer function takes our custom arguments, while the inner function handles the event that's passed by default. This Eliminates the need to define an arrow function for each event. Not only does that make your code look a lot cleaner, but it also gives you a legitimate use case for occurring, which will impress your friends and family. And that brings us to anti pattern number 10. When working with the useState hook in a component, it's tempting to put all of your data in a single object. It. It makes the code look cleaner and may also seem more performant because you only need to call set state once. However, what you should know is that React 18 will do automatic batching whenever you update the state. That means calling setState multiple times in the same function will not trigger multiple re renders. Therefore, it's not a big deal for performance, but more importantly, it makes your code difficult to extract into a custom hook. In the olden days with React class components, it was common to organize your code into smart components and dumb components, where the smart components control the data and the dumb components just render UI with props. There's nothing wrong with this pattern, but nowadays it's It's easier to just extract your logic into a custom hook. What I like to do is build my component with a bunch of different stateful values at first, Then if things get too complex, or I want to use that code in a different component, I extract it into my own custom hook, which itself is just a JavaScript function. It. This allows you to treat virtually all your components as dumb components, while your custom hooks handle the more complex business logic. And with that, we've looked at a small preview of the different things you can screw up in React. Check out my full course if you wanna learn more about React, and here's a special discount for making it all the way to the end of this video. Thanks for watching, and I will see you in the next one.
        