
React is a popular and powerful library for building user interfaces. However, as your application grows, performance can become a bottleneck. One technique for improving React app performance is by utilizing memoization, a technique that helps avoid unnecessary re-renders of components. In this article, we'll dive into when to use React.memo and how it can help boost your app's performance. We'll also discuss potential pitfalls of using React.memo incorrectly.

## What is React.memo?
React.memo is a higher-order component (HOC) that allows you to memoize the result of a component's render function. Memoization is the process of caching a function's output based on its input arguments, so the next time the function is called with the same arguments, it returns the cached result instead of recalculating it.

In the context of React, memoization allows you to avoid unnecessary re-renders of components by caching the component's result when the input props haven't changed. This optimization technique can significantly improve the performance of your React app, especially if you have complex or frequently updated components.

## When to Use React.memo?
Now that we understand what React.memo is let's explore when to use it. Generally, you should use React.memo when:

  - **The component is expensive to render**
  If a component's render function is expensive and produces a large subtree, it's a good candidate for memoization. By memoizing the component, you can avoid unnecessary re-renders and improve the overall performance of your app.

  - **The component renders frequently**
  If a component renders frequently, memoization can help you avoid unnecessary re-renders. For example, imagine you have a list of items, and each item has a button that can trigger a state update. If the list component isn't memoized, each time an item is updated, the entire list will be re-rendered. However, if you memoize the list component, React will only re-render the items that have changed, improving your app's performance.

  - **The component has a large number of props**
  If a component has a large number of props, memoization can help you avoid unnecessary re-renders. When you memoize a component, React will only re-render the component if any of its props have changed. By avoiding unnecessary re-renders, you can improve the overall performance of your app.

## How to Use React.memo?
Using React.memo is straightforward. You wrap your component in the React.memo function call and pass it as the argument. For example:

```javascript
Copy code
import React from 'react';

const MyComponent = React.memo(({ propA, propB }) => {
  // component implementation
});
```
In the example above, we've memoized MyComponent, which takes two props propA and propB. React will compare the input props of the component before rendering it. If the input props haven't changed, React will reuse the previously rendered result.

## Custom Comparison Function
By default, React.memo performs a shallow comparison of the input props to determine whether to re-render the component. However, you can provide a custom comparison function to React.memo to perform a more granular comparison. For example, if your component receives an array of objects as a prop, you might want to provide a custom comparison function to compare the objects' properties instead of the array reference itself.

```javascript
import React from 'react';

const MyComponent = React.memo(({ items }) => {
  // component implementation
}, (prevProps, nextProps) => {
  return prevProps.items.every((item, index) => {
    return item.id === nextProps.items[index].id;
  });
});
```

In the example above, we've provided a custom comparison function to React.memo that compares each object's id property in the items prop.

## Caveats of Using React.memo
While memoization can significantly improve the performance of your React app, it's essential to use it correctly. Here are some potential pitfalls to keep in mind:

- Over-memoization
One common mistake when using React.memo is over-memoization. Memoizing every component in your app can lead to decreased performance instead of improving it. Memoization incurs an overhead cost of storing and comparing the input props, so memoizing a component that renders quickly or infrequently might not be worth the cost.

- Memoizing Impure Components
Another potential pitfall of using React.memo is memoizing impure components. Impure components are components that depend on external state or have side effects, such as making an API call. Memoizing an impure component can lead to unexpected behavior and bugs, as React won't re-render the component when the external state changes or side effects occur.

- Inappropriate Custom Comparison Function
Finally, providing an inappropriate custom comparison function to React.memo can also lead to bugs and unexpected behavior. If your custom comparison function doesn't accurately reflect the component's input dependencies, React won't re-render the component when it should.

## Conclusion
In summary, React.memo is a powerful tool for optimizing React app performance. By memoizing components that are expensive to render, render frequently, or have a large number of props, you can avoid unnecessary re-renders and improve your app's overall performance. However, it's essential to use React.memo correctly and avoid common pitfalls such as over-memoization, memoizing impure components, and providing an inappropriate custom comparison function.

As a senior React developer, you should strive to understand the best practices for optimizing React app performance, and React.memo is an important technique to add to your toolbox. By using React.memo effectively, you can create fast and responsive React apps that provide an excellent user experience.

Maximizing React Performance: When and How to Use React.memo for Optimal Results

boost react performance with react memo when to use memo


When building a Next.js application, you'll likely find yourself creating shared components and templates that are used across multiple pages. One of the most powerful tools for achieving this is the use of Next.js layouts.

## What are layouts?

Layouts are higher-order components that wrap your page components in shared UI elements like headers, footers, and navigation menus. They're a way to extract common UI elements and stateful logic so that they can be reused across multiple pages.

With layouts, you can define the basic structure of your application once and reuse it across all of your pages. This can be particularly useful when you want to maintain a consistent user experience or when you have complex UI elements that need to be shared across multiple pages.

## The benefits of layouts

There are several benefits to using layouts in your Next.js application:

- **Consistency**: With layouts, you can ensure that your application has a consistent look and feel across all of your pages. This can help to improve the user experience and make your application feel more professional.

- **Reusability**: By extracting common UI elements and stateful logic into layouts, you can reuse them across multiple pages. This can help to reduce code duplication and make your application easier to maintain.

- **Maintainability**: By separating the concerns of layout and content, you can make your code more modular and easier to reason about. This can make it easier to make changes to your application in the future.

- **Performance**: By sharing components across multiple pages, you can reduce the amount of code that needs to be downloaded by the browser. This can help to improve the performance of your application.

- **Shared state**: By using layouts, you can share state between pages. This can be useful for things like maintaining a user's session or storing data that needs to be shared across multiple pages. The state be shared between all pages that are wrapped by the same layout.

## How to use layouts
To use a layout in your Next.js application, you'll need to create a layout component that wraps your page components. Here's an example of a simple layout component:

```tsx
import Header from './Header';
import Footer from './Footer';

const Layout = ({ children }) => (
  <>
    <Header />
    <main>{children}</main>
    <Footer />
  </>
);
export default Layout;

```

In this example, we're creating a layout component that includes a header and a footer. We're also using the children prop to render the content of our page.

To use this layout, we'll need to modify our _app.tsx file. Here's an example of what the modified _app.tsx file might look like:

```tsx
import type { AppProps } from 'next/app';
import Layout from '../components/Layout';

function MyApp({ Component, pageProps }: AppProps) {
  const getLayout = Component.getLayout || ((page) => <Layout>{page}</Layout>);
  return getLayout(<Component {...pageProps} />);
}

export default MyApp;

```

In this example, we're creating a custom MyApp component that wraps all of our page components in our Layout component. We're also defining a getLayout function that can be used by individual pages to define their own layouts.

Using TypeScript with layouts
If you're using TypeScript with Next.js, you may want to create a custom type for your layouts. Here's an example of how you might do that:

```tsx
import type { NextPage } from 'next';
import type { ReactElement, ReactNode } from 'react';

export type NextPageWithLayout<P = {}, IP = P> = NextPage<P, IP> & {
  getLayout?: (page: ReactElement) => ReactNode;
};
  
``` 

In this example, we're creating a new type called NextPageWithLayout that extends the NextPage type from Next.js. We

Now that we've defined our types and interfaces, let's implement them in our _app.tsx file. First, we need to import our new types and interfaces:

```tsx
import type { AppProps } from 'next/app'
import type { NextPageWithLayout } from '../types/NextPageWithLayout'
```

Next, we need to update our App component to include the layout functionality. We can do this by updating the Component prop to be of type NextPageWithLayout and then calling the getLayout function with the Component and pageProps.children as its arguments:

```tsx
function MyApp({ Component, pageProps }: AppPropsWithLayout) {
  const getLayout = Component.getLayout ?? ((page) => page)
  return <>{getLayout(<Component {...pageProps} />)}</>
}
export default MyApp

```

Here, we're checking if the Component has a getLayout function defined. If it does, we use it to wrap the Component and pass in pageProps.children as the content of the layout. If it doesn't, we simply render the Component without a layout.

With this setup, we can now easily define layouts for our pages by defining a getLayout function in each page's module file:

```tsx
import type { NextPage } from 'next'
import type { NextPageWithLayout } from '../types/NextPageWithLayout'
import Layout from '../components/Layout'

type Props = {
  title: string
}

const Page: NextPageWithLayout<Props> = ({ title }) => {
  return (
    <>
      <h1>{title}</h1>
      <p>This is a page with a layout.</p>
    </>
  )
}

Page.getLayout = function getLayout(page) {
  return <Layout>{page}</Layout>
}

export default Page
```

Here, we're defining a Page component that uses the NextPageWithLayout type we defined earlier. We're also defining a getLayout function on the component that returns the Layout component with the page content as its children.

With this setup, we can easily define layouts for all of our pages and ensure that they are all typed correctly using TypeScript. Additionally, we get the benefits of layouts like shared state and preserved state after page navigation.

## Conclusion

In conclusion, as a developer, I believe that Next.js layouts offer a simple and efficient way to structure your application's layout and manage state in a centralized and scalable manner. They provide a way to abstract away the complexity of managing shared components and state across pages, while also offering a clean and organized codebase. By using Next.js layouts, I have found that I can save time and resources while also improving the overall user experience.

I hope this article has helped you understand the benefits of using Next.js layouts and how to implement them in your projects. Remember, layouts are not a requirement, but they can greatly improve the structure and maintainability of your code. Happy coding!

Streamlining Next.js Development with Layouts Achieving Consistency, Reusability, and Improved Performance

Next.js Layouts Explained


React is a popular front-end framework that allows developers to build scalable and maintainable web applications. However, building components in React that are both testable and maintainable can be a challenge. In this article, we will explore some best practices for designing React components that are easy to test and maintain.

# Separating Concerns

One of the key principles of building testable and maintainable React components is to separate concerns. Each component should have a clear responsibility and not be overly complex. This means that each component should have a single purpose, and be reusable across different parts of your application.

When designing your components, it’s important to keep in mind the Single Responsibility Principle (SRP). Each component should have a clear and well-defined responsibility, which should make it easier to test and maintain. You don't want to end up with a massive, monolithic component that's difficult to work with and understand. Instead, try to break up larger components into smaller, more focused ones. This not only makes it easier to test and maintain each component, but also makes it easier to reuse them across different parts of your application.

# Dependency Injection

Dependency injection is another best practice for designing testable React components. Dependency injection means passing in dependencies as props rather than relying on global state or accessing them directly.

Passing in dependencies as props makes it easier to test your components in isolation. You can create a mock version of a dependency and pass it in during testing, ensuring that your component behaves as expected. This is especially important when dealing with complex dependencies such as APIs, databases, or third-party libraries. Using dependency injection also helps keep your components decoupled, making them easier to maintain and modify. If a dependency changes, you only need to update the code in one place, rather than throughout your entire application.

# Immutable Data

React encourages the use of immutable data, which means that the data in your application cannot be changed directly. Instead, you create a new copy of the data every time it needs to be updated.

Immutable data makes your components easier to test, as you can be sure that the data your component is working with won’t change unexpectedly. It also makes your components more maintainable, as you can be confident that the data they’re working with is always up to date. Immutable data is particularly useful when dealing with large, complex data structures. It makes it easier to reason about your data and reduces the risk of bugs caused by unintended side effects.

# Stateless Components

Stateless components are another best practice for building testable and maintainable React components. Stateless components do not have any internal state, meaning that their behavior is entirely determined by their props.

Stateless components are easier to test than stateful components, as they have fewer moving parts. They are also easier to reason about, which makes them more maintainable in the long run. However, not all components can be stateless. If a component needs to maintain some state, it’s important to keep that state as minimal as possible, and to make sure that it’s clearly separated from the rest of the component’s logic.

# Accessibility

Ensuring that your components are accessible is an important consideration when building testable React components. Accessibility testing involves ensuring that your application can be used by people with disabilities, such as those who are visually impaired or have limited mobility.

When building accessible components, you should consider how they will be used by people with different abilities. For example, you might need to include alternative text for images, or ensure that all interactive elements can be navigated using a keyboard. By building accessible components, you not only make your application more inclusive, but you also make it easier to test, since accessibility issues are often flagged by automated testing tools.

# Error Handling
A
nother important consideration when designing testable React components is error handling. Your components should be able to handle errors gracefully, without crashing the entire application. This involves using error boundaries to catch and handle errors at the component level, rather than letting them propagate up to the global error handler.

By handling errors at the component level, you can ensure that your application remains stable and continues to function even when errors occur. You can also test error handling scenarios more easily, since you can use mock data to simulate different error conditions and verify that your components respond appropriately.

# Component Composition

Component composition is the process of combining smaller, reusable components to build more complex ones. By composing your components in this way, you can create a more modular and maintainable codebase.

From a testing perspective, component composition makes it easier to isolate and test individual components. Rather than testing a complex, monolithic component, you can test each smaller component in isolation, ensuring that each one works as expected. You can also use mock data to simulate different scenarios and verify that your components behave correctly in different situations.

# Conclusion
In conclusion, designing testable and maintainable React components requires careful consideration of a variety of factors. By separating concerns, using dependency injection, using immutable data, using stateless components, ensuring accessibility, handling errors gracefully, and using component composition, you can build components that are not only testable and maintainable, but also accessible, resilient, and modular. By focusing on these best practices, you can create components that provide value to your application for years to come, while also making it easier to collaborate with other developers and ensure the ongoing success of your project.

Make your React components testable and maintainable by following these best practices.

Designing React Components that are Testable and Maintainable


## What is react-query / tanstack query ?

React Query, now known as the Tan Stack Query, is a powerful tool for managing and fetching data in your React application. It was designed to be lightweight and easy to use, making it a popular choice for developers looking to streamline their data management processes.

One of the main benefits of React Query is its ability to handle data fetching and caching automatically. When you make a request for data, React Query will first check to see if the data is already stored in its cache. If it is, the cached data will be returned immediately, resulting in a much faster response time for the user. If the data is not in the cache, React Query will make a request to the server to fetch the data and then store it in the cache for future use.

Another key feature of React Query is its ability to handle real-time updates to data. When a request is made to update data on the server, React Query will automatically refetch the data and update the cache, ensuring that your application always has the most up-to-date information. This is especially useful for applications that rely on real-time data, such as social media feeds or messaging apps.

One of the more advanced features of React Query is its support for pagination and infinite scrolling. This allows you to load large datasets in smaller chunks, making it easier to manage and reducing the load on your server. It also provides a better user experience, as the user can scroll through data indefinitely without having to manually click through pages.

React Query also makes it easy to handle errors and retries. If a request fails, React Query will automatically retry the request a set number of times before giving up. It will also handle error display for you, making it easy to let the user know if something has gone wrong.

Overall, React Query is a powerful tool for managing and fetching data in your React application. Its automatic caching, real-time updates, pagination support, and error handling make it a great choice for developers looking to streamline their data management processes.

## What problems does react-query solve?

React Query is a tool for managing and fetching data in a React application. It was designed to solve several common problems that developers often encounter when working with data in a React app, such as:

- **Managing data fetching**: Fetching data from an API or other external source can be a complex and error-prone process. React Query makes it easy to fetch and cache data, automatically retrying failed requests and handling error display for you.

- **Real-time data updates**: In many applications, data is constantly changing on the server and it is important to keep the client up to date with the latest information. React Query makes it easy to fetch and update data in real-time, ensuring that your application always has the most up-to-date information.

- **Pagination and infinite scrolling**: When working with large datasets, it is often necessary to split the data up into smaller chunks to make it more manageable. React Query provides support for pagination and infinite scrolling, allowing you to load data in smaller chunks and providing a better user experience.

- **Caching and performance**: Caching data can significantly improve the performance of your application, particularly for data that does not change frequently. React Query automatically caches data and can be configured to cache data for a specific period of time, ensuring that your application is fast and responsive.

Overall, React Query helps developers solve a variety of data management challenges in their React applications, making it easier to build powerful and efficient apps.

## Practical examples of react-query

Here are a few examples of how you might use React Query in your application:

**Infinite scrolling**:

```jsx
import { useQuery } from "react-query";

function App() {
  const { status, data, error, isFetching } = useQuery(
    ["posts", { page: 1 }],
    () => fetch(`https://my-api.com/posts?page=1`).then((res) => res.json())
  );

  const handleScroll = () => {
    if (
      window.innerHeight + document.documentElement.scrollTop !==
      document.documentElement.offsetHeight
    )
      return;

    setPage((prevPage) => prevPage + 1);
  };

  useEffect(() => {
    window.addEventListener("scroll", handleScroll);
    return () => window.removeEventListener("scroll", handleScroll);
  }, []);

  if (isFetching) return "Loading...";
  if (error) return "An error occurred";

  return (
    <div>
      {data.posts.map((post) => (
        <div key={post.id}>{post.title}</div>
      ))}
    </div>
  );
}
```

In this example, we are using the useQuery hook to fetch a page of posts from an API endpoint. The handleScroll function is used to detect when the user has scrolled to the bottom of the page, and when this occurs, the page number is incremented and a new query is triggered to fetch the next page of data. This allows the user to scroll through an infinite number of pages of data.

**Fetching data**:

```jsx
import { useQuery } from "react-query";

function App() {
  const { status, data, error, isFetching } = useQuery("user", () =>
    fetch(`https://my-api.com/user`).then((res) => res.json())
  );

  if (isFetching) return "Loading...";
  if (error) return "An error occurred";

  return (
    <div>
      <h1>{data.user.name}</h1>
      <p>{data.user.email}</p>
    </div>
  );
}
```

In this example, we are using the useQuery hook to fetch a single user from an API endpoint. The hook handles all of the caching and error handling for us, making it easy to display the data to the user.

I hope these examples give you a good idea of how you can use React Query in your own application. There are many more features and capabilities available, so be sure to check out the documentation for more information.

## Conclusion

In conclusion, React Query is a powerful tool for managing and fetching data in a React application. It simplifies common data management tasks such as fetching, caching, and real-time updates, making it a great choice for developers looking to streamline their data management processes. Its support for pagination and infinite scrolling, as well as error handling and retries, make it a comprehensive solution for data management in React. If you are looking to improve the way you manage data in your React app, React Query is definitely worth considering.


Streamline Your Data Management with React Query

React Query


If you've worked on any react or next.js application in the past, you've probably noticed that it's very unopinionated in general, especially when it comes to how you handle async. Which played a big role in how we've fetched data in our react applications. So far we've either used `useEffect`, `useSWR` or more recently [react-query](https://tanstack.com/query/v4). But now we're getting an exciting new feature in react that will make all things async especially data fetching a lot easier.


## Introducing the use hook
[More info here](https://github.com/acdlite/rfcs/blob/first-class-promises/text/0000-first-class-support-for-promises.md)


Essentially, we're finally getting a native way to handle async functionallity in React. Meaning we don't really need to relly on `useEffect` to fetch our data we can simple create an axios fetch request and wrap it in a `use` hook. 

For example:
```tsx
export const Post = (id:string) => {
  const fetchPost = axios.get(`/api/posts/${id}`));
  const post = use(fetchPost);
  return (
    <div>
      <h1>{post.title}</h1>
      <p>{post.body}</p>
    </div>
  )
}
```
This will fetch the post data and render it on the page. No `useEffect` required or any other async handling library required. 🎉

## How does the use hook work

Similary to `await` it simply unwraps the value of a promise, meaning that any async behaviour can be wrapped in a use hook now and react will natively handle the promise for us.

## Do we still need react-query then?

Yes, we do. While the use hook is a great addition to react, it's still not a replacement for react-query. The use hook is only meant to handle async behaviour, not caching or any other advanced features. So if you're looking for a more advanced data fetching library, react-query is still the way to go. However it's a step in the right direction for the react team and a welcome addition to the react ecosystem. I can't wait to see what the community does with this new feature. 🤩

## Other interesting stuff of note

Unlike all other hooks the `use` hook appears to support conditional execution. Much like react-query's `enabled` option. This means that we can conditionally fetch data based on some condition. This is of course not supported by other hooks and it appears that the use hook is the only hook will support this. A cool future proposal in the RFC is that we can wrap React Context in a use hook as well. Which would allow us to use context in a more declarative way. Not sure if this will make it into the final RFC but it's an interesting idea.


## Conclusion

This is by far one of the coolest upcoming features in react. I personally can not wait to use it in my next project. I'm sure we'll see a lot of interesting use cases for this new hook. If you're interested in learning more about the use hook, I highly recommend you check out the RFC. It's a very interesting read and it's a great insight into how the react team thinks about new features.



Introducing the use Hook: A Native Way to Handle Async in React

React Just Got Even More Awesome


Have you ever worked on an application that had a ridicolous amount of lines in every single component. Noticed how it was really hard to find the relevant part of the code that you wanted to fix or improve, noticed how a lot of times certain functionality would repeat itself in different components, and how it was really hard to maintain and test?

Or how about the other extreme, were you ever horrified to open up the **components** folder only to be greeted by a waterfall of files and folder. Multiple of those files only being used once or twice in the code base.

Both of those approaches are not ideal, and both of them are very common. So how do we find the right balance? **How granular should our components be?**

Let's start off by tackling the first extreme.

## Big do-all components

The first extreme is the one that I have seen the most. The one where a component has a lot of lines of code, and a lot of different responsibilities. A confusing mess of code that is hard to maintain and test. But how does it come to this in the first place, what drives a developer to write such a components? Well there are a few reasons for this and understanding why it happens is a good way to prevent it from happening in the first place.

### 1. No planning phase

This is by far the most common cause of the issue, and it is also the easiest to prevent. The problem is that a lot of developers don't plan out their components before they start writing them. They just start writing code and then they realize that they need to add some more functionality, so they just add it to the component. And then they realize that they need to add some more functionality, and so on and so on. This can very easily be prevented by simply planning out your components and functionality before you write a single line of code. There are a few methods that you can use to do this. For instance what generally helped me get started was simply writing down a skeleton of a component with comments before I started writing the actual code. This way I could plan out the functionality and the structure of the component before I started writing it.

Here's how something like that would look like

```tsx
// MainNavigation.tsx

/*
This component is responsible for rendering
the main navigation of the app
*/
/*
  Props:
    - links: an array of links that should be rendered in the navigation
    - activeLink: the link that is currently active
    - onLinkClick: a function that is called when a link is clicked
*/

// implement the component here
export const MainNavigation = () => {
  // destructure the props

  // define the component's state

  // define onLinkClick handler

  // render the component
  return {
    /*
    We want to display a logo on the left side of the navigation
    NOTE: the likelyhood of the logo being re-used in 
    other parts of our application is quite low
    so we can just render it here, no extra component needed
    */
    /*
    render the links out here
    NOTE: we should probably implement a Link 
    component that we can use here
    it would take a single prop of type Link and render it out
    */
    /* 
    we do have user authentication so a user menu 
    for authenticated users is a must
    NOTE: the user menu is likely to be 
    re-used in other parts of the application
    so we should probably implement a 
    UserMenu component that we can use here

    Additionally the usermenu should turn into a 
    login and signup button when the user is not authenticated
    this additional complexity is a good argument for 
    implementing a UserMenu component
    */
  };
};
```

As you can see in the example above we've already planned out the structure of our `MainNavigation.tsx` component and we've also planned out the functionality that we want to implement. This way we can make sure that we don't add too much functionality to a single component. Additionally as I was skeletoning out the component I noticed good candidates for separate components. For instance the `UserMenu` and the `Link` components. This way we can make sure that we don't end up with a big do-all component.

Now we can start writing the actual code for our component, which can look something like this

```tsx
interface ILink {
  text: string;
  href: string;
}
interface IProps {
  links: Link[];
  activeLink: Link;
  onLinkClick: (link: Link) => void;
}

export const MainNavigation = (props: React.PropsWithChildren<IProps>) => {
  const { links, activeLink, onLinkClick } = props;
  const [isMenuOpen, setIsMenuOpen] = useState(false);

  const handleLinkClick = (link: Link) => {
    setIsMenuOpen(false);
    onLinkClick(link);
  };

  return {
    <div className="logo">
      <img src="logo.png" alt="logo" />
    </div>

    {links.map((link) => (
      <Link
        key={link.href} // NOTE: use a stronger key here
        link={link}
        isActive={link.href === activeLink.href}
        onClick={handleLinkClick}
      />
    ))}

    <UserMenu />
  }
}
```

And just like that we've written a clean and maintainable component. The component is easily readble, understandable and testible. We correctly discovered where further separation of concerns was needed.

### 2. Lack of experience

If you're new to react or web development in general the term separation of concerns might be foreign to you. It's nothing too complex it simply means that generally speaking each component should do one thing and do it well sorta like the original UNIX ethos. Meaning each component should be responsible for a single part of your application, e.g: you want a Navigation component to handle the navigation of your application, you want a LanguageSwitcher component to handle language switching, footer component to display the footer, UserMenu to render the user menu and so on. This way you can easily re-use your components in other parts of your application. Additionally it makes your components easier to test and maintain.

### 3. Team size / mentorship

If you're working in a small team or going solo on a project, it's very easy to fall into bad habbits like writing big do-all components. this is because working in a team or collaborating with other people naturally forces you to write cleaner and more maintainable code especially if you have any mentorship processes in place such as: pair programming, code reviews, etc.

But you may be wondering, "ok Dave but what if I'm working on a hobby project or my own solo project, I can't reap the benefits of working in a team".

Well you're partially right, there's one very easy solution to your problems it's called **open source**, if you simply open up your project to the world and let other people contribute to it, you'll naturally want to write cleaner and maintainable code since you will know that eventually other people will look at your code and we all want to put our best foot forward when we know other people are looking don't we. Additionally open sourcing your project will allow other people to contribute to it, which is a great way to learn and improve your skills.

If you're however already working in a team but don't have any mentorship processes set up I highly recommend you to look into them, they will help you and your team write cleaner and more maintainable code.

### 4. Pressure to deliver / lack of time

This one is fairly common, perhaps you work in a team where you're under a lot of pressure to deliver, in a constant push to get features out the door. This can lead to a lot of bad habbits such as writing big do-all components, not writing tests, not writing documentation, etc. This is a very common problem in the industry and it's not easy to solve. But I think the best way to solve it is to simply talk to your team lead or manager and let them know that you're struggling with the pressure to deliver and that you would like to focus on solving some of these issues that may seem trivial and unimportant but can very easily snowball into a big problem later on.

These four points are just some of the possible reasons why your codebase might be littered with huge components that do everything. I'm sure there are many more reasons out there, but I think these are the most common ones.
Which brings us to the opposite extreme

## A ton of small components

This is the opposite extreme of the previous problem, you can very easily take a good thing like separation of concerns and take it too far and ruin it by overdoing it. It always reminds me of one of my favorite quotes:

> Premature optimization is the root of all evil
>
> ~ Donald Knuth

Simple, elegant and eloquent. It applies to our scenario perfectly. Too many times developers will rush and start making different components for every single thing without ever stopping to think if this component will ever really be used in more than once place. If the answer is no, then it simply does not need to be it's own component. Here's where I'll resort to using a quote yet again to drive my point home, in this example I'll be usig Dan Abramov's famous twitter thread:

> It is a guideline though. It means literally “start by putting everything in one file; when it feels like it’s annoying, start splitting them up; what THAT gets annoying, maybe add some folders”.
>
> ~ [Dan Abramov](https://mobile.twitter.com/dan_abramov/status/1027248875072114689)

Now this may go against my previous advice to carefully scaffold out your components and functionallity via comments, but I don't think that what Dan meant there was to write a huge component and then split it up into smaller components, I think he meant to start with a single file and then split it up into smaller components as you go along. This way you can make sure that you don't overdo it and end up with a ton of small components that are only used in one place.

## Conclusion

In this article we've talked about two extremes of the same problem, big do-all components and a ton of small components. We've also talked about some of the possible reasons why you might end up with either of these two problems. I hope you've learned something new and I hope you'll be able to apply this knowledge to your own projects. If there's one take away from this article it's this: try and plan out your components and functionallity before you start writing code, but don't overdo it either. Try and find a good balance that works well for you and your team. Both big do-all components and component waterfalls are huge issues that can easily be fixed by simply taking a step back and thinking about your code.

Adopt a measure twice cut once approach to your code and you'll be fine.

Hope you enjoyed this article, if you did please consider sharing it with your friends and colleagues. If you have any questions or comments feel free to reach out to me on twitter: [@dayvsterdev](https://twitter.com/dayvsterdev)


Avoiding the Two Extremes of Component Design: Finding the Right Balance for Your Application's Codebase

How granular should components be?


Are you sick of redux boilerplate, tired of wating for recoil to finally release a stable version, afraid of misspronouncing the word "zustand"? Well, you're in luck! React context is here to save the day!
Or is it? Let's find out!

## What is React Context

To put it simply React Context simply another way that you can tackle your app state or global state in your react or next.js application. React context allows you to create a state provider or "context" that wraps around your components and lets them access the it's state. You can have one big global context and simply wrap your entire application in it, or you can have multiple isolated contexts that are only used in specific parts of your application that needs to share a common state.

All this without the need for a third party library, and without the need to use redux or any other state management library. Sounds great, right? Well, it is, but there are some downsides to using context. Which we'll get into later.

## When to use React Context

This is the big question when it comes to react context, it falls into this odd category where you don't really need to use it for small and simple applications and if you're building a very complex big application with a lot of moving parts you're probably better off using something like zustand or even redux if you're a masochist.

So when should you use react context then? A good rule of thumb is to use it when you want to share a specific state between multiple components, but you're fairly certaint that state is not expected to change very often. A good example of this would be:
a theme switcher. You want to be able to switch between light and dark mode, but you don't expect the user to switch between the two modes very often. So you can create a context that holds the current theme and wrap your entire application in it. Then you can use the context to change the theme and all your components will be able to access the current theme.

Another good example would be a language switcher. You want to be able to switch between different languages, but you don't expect the user to switch between the languages very often. So you can create a context that holds the current language and wrap your entire application in it. Then you can use the context to change the language and all your components will be able to access the current language.

## Why is react context not recommended for frequent state changes

There are multiple reasons why you should not use react context for frequent state changes. The first reason is that react context makes it very easy for the developer to create useless re-renders, this can easily be avoided by utilizing the `useMemo` or `useCallback` hook. However we should be pretty picky on when to use these two hooks as their overuse can slow down your application even further. Then there's the problem of react context not really handling growing app complexity all that well. For example if we have something like zustand we can split our state into multiple stores or "slices". Each slice can contain any number of data and/or methods. We can then call these slices from anywhere within our application and access their methods or members.
React context also ... kida sorta maybe does this, you can immitate that functionality quite well with react context but it's never as scalable or extensible as something like zustand.

## So when should I even use react context?

Apart from the already aboved mentioned examples here's a good "flowchart" I like to follow mentally when deciding whether or not to use react context:

> Q: Do I have an issue that would require prop drilling deeper than 3 levels deep?
>
> A: Yes.
>
> Q: Would it not make sense to put it into redux or zustand?
>
> A: Yes.

Use react context.

## How to use React Context

Okay so now that we've basically trampled all over react context, you're probably thinking

> Why Dave you must absolutely hate react context and probably think it's trash.

No, not at all. I love react context, I think it's a godsend. In fact I think it's an insanely useful tool that can solve a lot of problems and make your life as a developer a lot easier. But just like every tool it's important to understand what it's intended for and what it's not intended for. You wouldn't wanna hammer in a nail with a screwdriver after all and you probably would not assume the screwdriver is trash just because it's not a hammer.

### Creating a context

Creating a context is super simply all you have to do is call the `createContext` function and pass it a default value, or initial state. If you're using typescript and bonus points if you are this will let react context know what kind of data it can expect to store.

```tsx
import { createContext } from "react";

// Create the context
const LanguageContext = React.createContext({
  language: "en",
  setLanguage: () => {},
});
```

Above we've created a context that holds the current language and a method to change the language. We've also set the default language to english or "en" for short.

### Context provider

Now that we've created our context we need to create a provider for it. The provider is the component that wraps around all the other components that need to access the context.

```tsx
import { createContext } from "react";

// Create the context
const LanguageContext = React.createContext({
  language: "en",
  setLanguage: () => {},
});

interface IProps {}

// Create the provider
const LanguageProvider = (props: React.PropsWithChildren<IProps>) => {
  const [language, setLanguage] = React.useState("en");

  return (
    <LanguageContext.Provider value={{ language, setLanguage }}>
      {children}
    </LanguageContext.Provider>
  );
};
```

Here we've added a context provider that can later wrap around all the components that require access to the context. This is done via the `children` prop which we then access by destructuring `props`.

### Using and updating the context

Now that we've created our context and our provider we can finally start using it. To use the context we simply need to import it and then call the `useContext` hook. The `useContext` hook takes the context as it's only argument and returns the context's value.

```tsx
import { createContext } from "react";

// Create the context
const LanguageContext = React.createContext({
  language: "en",
  setLanguage: () => {},
});

interface IProps {}

// Create the provider
const LanguageProvider = (props: React.PropsWithChildren<IProps>) => {
  const [language, setLanguage] = React.useState("en");

  return (
    <LanguageContext.Provider value={{ language, setLanguage }}>
      {children}
    </LanguageContext.Provider>
  );
};

// Use the context
const LanguageSwitcher = () => {
  const { language, setLanguage } = React.useContext(LanguageContext);

  return (
    <div>
      <button onClick={() => setLanguage("en")}>English</button>
      <button onClick={() => setLanguage("sv")}>Swedish</button>
    </div>
  );
};
```

Now whenever we want to change the language we can simply call the `setLanguage` method and all the components that are wrapped in the provider will be able to access the new language.

## Conclusion

React context is a very powerful tool that can be used to solve a lot of problems. However it's important to understand what it's intended for and what it's not intended for. If you're building a small and simple application you probably don't need to use react context at all. If you're building a very complex application with a lot of moving parts you're probably better off using something like zustand or even redux(masochist). But if your use case is wanting to store some piece of state somewhere and not expecting it too change very often and you wish to keep it independant from any third party libraries AND you also don't really feel like prop drilling too much then react context is probably the best tool for the job.


React context can be a very powerful tool, but when and why should you use it?

How and when to use React Context


## 1. Functional components

There really is no clear winner between functional and class components. However, functional components are easier to read and test because they are plain JavaScript functions without state or lifecycle-hooks. You end up with less code, and typically this results in faster development. Not to mention with the arrival of hooks, react developers have had the ability to abstract state and other operations into reusable functions. That are easily implemented within functional components.

For example:

```tsx
const MyComponent = () => {
  const [count, setCount] = useState(0);
  const increment = () => setCount(count + 1);
  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={increment}>Click me</button>
    </div>
  );
};
```

reads far better than

```tsx
class MyComponent extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      count: 0,
    };
  }
  increment() {
    this.setState((state) => ({
      count: state.count + 1,
    }));
  }
  render() {
    return (
      <div>
        <p>You clicked {this.state.count} times</p>
        <button onClick={() => this.increment()}>Click me</button>
      </div>
    );
  }
}
```

Notice how both of these components do the same thing, but the functional component is much easier to read and understand. Not to mention it quite helpfully explains itself at the very top, so it reads much nicer top to bottom.

## 2. Hooks

We've had hooks for a while now they've been recieved insanely well by the react community at large, with good reason as well. They are simply awesome and make react development a real joy. They allow you to abstract state and functionallity into reusable functions that can be used within functional components. This is amazing for react developers as it allows us to write less code and have more control over our components. For example:

```tsx
const useCounter = (initialState = 0) => {
  const [count, setCount] = useState(initialState);
  const increment = () => setCount(count + 1);
  const decrement = () => setCount(count - 1);
  const reset = () => setCount(initialState);
  return { count, increment, decrement, reset };
};
```

This is a custom hook that allows us to abstract state and functionality into a reusable function. This can then be used within functional components like so:

```tsx
const MyComponent = () => {
  const { count, increment, decrement, reset } = useCounter(0);
  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={increment}>Click me</button>
    </div>
  );
};
```

## 3. Typescript

Typescript is a superset of javascript that adds static typing to javascript. If you're not using typescript yet or have never used a statically or storngly typed language before your first thought might be well what's the point isn't much easier to to have to worry about types. However, the benefits of using typescript are numerous and far outweigh the cons. Especially when working in a team of any size. Essentially it ensures that you and your team are on the same page when it comes to the types of data that are being passed around. This is especially important when working with react as it allows you to ensure that the data you're passing to your components is of the correct type. For example:

```tsx
export interface IPerson {
  name: string;
  age: number;
}
export const Person = (props: React.PropsWithChildren<IPerson>) => {
  const { name, age } = props;
  return (
    <div>
      <h1>{name}</h1>
      <p>{age}</p>
    </div>
  );
};
export default Person;
```

As you can see in the example above we define an interface that describes the type of data that we expect to be passed to our component. This ensures that age for example will always be a number and not a string, this is especially important if we expect certain functions to run on our props. You are all familiar with the good old

```js
"100" - 1; // returns 99
"100" + 1; // returns 1001 because concatenation
```

Only you can prevent type errors.

## 4. State

You are probably already familiar with react state in some shape or form you've probably used the `useState` hook in some shape or form or perhaps you've used Redux, maybe just maybe you even delved into libraries like zustand, recoil, jotai and so on. This is all fine and good, but what will really set you apart from the rest is not always thinking about state as just one singular thing, if anything there's 3 types of state.

### Server State or Remote State

This is the state that lives somewhere on a remote server. It can change drastically and dramatically in any given time frame depending on the type of data it contains, e.g: say you wish to create a webapp that allows your users to view current stock or crypto values. We all know how much these things can fluctuate on a second by second basis. At a certain point you will have to think about how you wish to sync your client state to the remote state. This is where libraries like React Query and SWR come in handy, they make it easy for us to sync our client state with our remote state frequently and efficiently.

The wrong approach would be to simply cram all of this into our global state or application state, which brings us to:

### Application State

This is the state of your application and only your application, the server does not need to know about any changes to this state. For example what belongs in here would be: current user, theme, user settings, currently playing(video/audio) etc.

This is were you would use a library like Redux, Zustand, Recoil or Jotai to manage your application state. You could even use something like the built in react Context, however I'd urge you to use Context only when you are not expecting your Context state too change very often. This is because Context is not very performant and can cause unnecessary re-renders. Plus it's a massive pain to use and test.

### Local State or Component State

This is the state of your component and only your component. This is where you would use the `useState` hook. This is where you would store things like: checkbox state, form values, modal state, dropdown state, etc.

This state should optimally live and die with your component.

## 5. Testing

Ah testing, we all know it's of vital importance and yet we never get around to doing it or if we do then we usually do it improperly. But trust me it's crazy how many headaches can be avoided by simply writing unit tests, let alone integration tests and e2e tests. How to write good tests and how to write them properly is a whole other topic, but I'll give you a few tips that will help you get started.

### Unit Tests

When tackling unit tests always think small, what is the smallest and most vital bit of functionallity that I can test, this may be a hook, function or even a component. Also make sure to test your components in isolation, this means that you should mock any dependencies that your component may have. For example if you have a component that fetches data from an API, you should mock the API call and return some dummy data. This ensures that your test is not dependent on the API and will always return the same data.

### Test Driven Development - TDD

TDD is a fantastic way to tackle complex problems as it forces you to break functionallity down into it's smallest parts. Basically in test driven development you flip the script on it's head and write the test for the expected result first and then and only then work on the implementation all the while optimally running your testing framework in "watch" mode so that it runs your tests every time you save a file. Keep coding out the functionallity of your function, hook or component untill the test passes. Tadah you've just done test driven development and after that dot goes from red to green you get a hit of dopamine that will keep you going for hours.

### Integration Tests

Integration tests are a bit more complex than unit tests, but they are still relatively easy to write. Integration tests are used to test how different parts of your application interact with each other. For example if you have a component that fetches data from an API and then displays that data in a table, you would write an integration test that tests that the data is fetched from the API and then displayed in the table. This is a bit more complex than unit tests as you will have to mock the API call and return some dummy data. You will also have to mock the table component and return some dummy data. This ensures that your test is not dependent on the API and will always return the same data.

### End to End Tests

End to end tests are the most complex of all tests, but they are also the most important. End to end tests are used to test how your application behaves from start to finish. For example if you have a component that fetches data from an API and then displays that data in a table, you would write an end to end test that tests that the data is fetched from the API and then displayed in the table. This is a bit more complex than unit tests as you will have to mock the API call and return some dummy data. You will also have to mock the table component and return some dummy data. This ensures that your test is not dependent on the API and will always return the same data.

## 6. Composition vs Inheritance

**Composition** is when we create multiple components with their own functionallity and then combine them together to create a more complex component. This is the preferred way of creating components in React.

**Inheritance** is when we create a component that inherits the functionallity of another component. This is not the preferred way of creating components in React.

Example of composition:

```tsx
interface ICheckbox {
  checked: boolean;
}
export const Checkbox = ({ checked }: ICheckbox) => {
  return (
    <div>
      <input type="checkbox" value={checked} />
    </div>
  );
};

interface ISetting {
  name: string;
  value: boolean;
}
export const Setting = ({ name, value }: ISetting) => {
  return (
    <div>
      <span>{name}</span>
      <checkbox value={value} />
    </div>
  );
};
```

In the above example we have a checkbox component (albeit a bad one when it comes to reactivity) and a setting component that uses the checkbox component to display a setting. This is a good example of composition. We could take it even further by then creating a settingsList component that uses the setting component to display a list of settings. That same component could also use other components such as buttons, inputs, headings etc. all this via composition.

Example of inheritance:

```tsx
export class Button extends React.Component {
  render() {
    return <button>{this.props.children}</button>;
  }
}

export class PrimaryButton extends Button {
  render() {
    return <button className="primary">{this.props.children}</button>;
  }
}
```

In the above example we created a button component named `Button` and then another component named `PrimaryButton` that inherits the functionallity of the `Button` component. This may in the future make our life a bit more difficult as we may want to add a new functionallity to the `Button` component, but we don't want that functionallity to be inherited by the `PrimaryButton` component. Say for example we want to add a `disabled` prop to the `Button` component, but we don't want that prop to be inherited by the `PrimaryButton` component.

## 7. Join the React Community

React has grown into an absolute behemoth and likewise the community around it has grown exponentially over the years. Now going at it solo is all fine and good, but you will find that you will hit a wall at some point and you will need help. This is where the community comes in. There are a ton of resources out there to help you get unstuck, but I'll give you a few of my favorites.

- [Reactiflux](https://www.reactiflux.com/) - The official React Discord server
- Dan Abramov's [Twitter](https://twitter.com/dan_abramov) - Dan is the creator of Redux and the author of the React docs
- [React Twitter](https://twitter.com/reactjs) - The official React Twitter account
- [Ben Awad](https://twitter.com/benawad) - Ben is a full stack developer and React developer extraordinaire not to mention deadpan comedy expert
- [React Docs](https://reactjs.org/docs/getting-started.html) - The official React docs explore them, they are a goldmine of information

## 8. Bonus: Hack around and have fun

This is the most important part of all, have fun. React is a fantastic tool and it's a joy to work with. So hack around, break things, make things, learn things, have fun. That's what it's all about.
