
## 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.


React Query


## TurboPack
So nextConf just happened and they announced a couple of super cool things like TurboPack, a next.js bundler that promises to be a lot faster than vite and insanely faster than webpack. How much faster you may wonder, well according to their announcement it promises to be 10x faster than vite, and 700x faster than webpack.

How much that will actually matter in the real world, I can't say. But it's definitely a step in the right direction and should help you keep those build minutes down on your favorite cloud provider. 

## OG Image Generation
Then there's OG Image generation, which is a super cool feature that I'm already using on my blog. Basically it let's you define a new API route that will act as an image generator. You provide the contents of the image via HTML and CSS and when you call the API route, it returns the image for you. Here's how it works: 

```tsx
// pages/api/og-image.ts
import { ImageResponse } from "@vercel/og";
import { NextRequest } from "next/server";

export const config = {
  runtime: "experimental-edge",
};
export default function ImageGenerator(req: NextRequest) {
  const { searchParams } = new URL(req.url);
  const text = searchParams.get("text")
  return (
    <div
      style={{
        width: 1200,
        height: 630,
        backgroundColor: "white",
        display: "flex",
        justifyContent: "center",
        alignItems: "center",
      }}
    >
      <h1>{text}</h1>
    </div>
  );
}

```

Now every time you call the API route, it will return an image with the text you provided in the query parameters.


## File System Routing Extended

Next.js had a file system router from it's very inception, but now that router is getting a huge update. Every directory can have an `index.tsx` or `index.jsx` well that's about to change with next13. They're opting for a more directory based approach with their routing. Basically all your routing will now live in an `app directory` and you define your routes in there by creating a subdirectory for each route. Furthermore you can template out your route with the following files:

- `page.tsx` - the base component that you wish to display on that route e.g `app/home/page.tsx` may contain the home page component
- `layout.tsx` - provides a shared layout for your route and all of it's subroutes
- `loading.tsx` - will be rendered while the page is loading
- `error.tsx` - will be rendered if an error occurs while loading the page

I'm not too sure how I feel about this, as I find that file system routing can quickly grow into a bit of a mess that may be hard to navigate. But luckily you can still use the old file system routing if you wish to do so and adopt the new one procedurally. Which is also a concern if I'm honest since we all know there's plenty of teams out there that will due to time pressure or other unforseen circumstances just get to migrate half of their app to the new file system routing. Which will force them to maintain two different routing systems in the same app. So if you're reading this and getting ready to port everything to the new file system routing, please make sure to schedule enough time for it to fully finish it. Save yourself the headache.

**BUT I've saved the coolest feature by far for last**

## Data Fetching

Now this is the one feature I and many other developers are really excited about, what it means is that you can now simply add async to your component and it will automatically be treated as a react server side component. Meaning that it will be rendered on the server and streamed to the client. This is a huge step forward for next.js and will make it a lot easier to build apps that are fast and performant. Not to mention it will reduce the need for external third party libraries to do this for us such as React Query. How it works is:

```tsx
// pages/index.tsx

export default async function Home() {
  const data = await fetch("https://api.example.com", {
    next: {
      revalidate: 60, // when to revalidate cache in secods
    }
  });
  return (
    <div>
      <pre>
        {JSON.stringify(data, null, 2)}
      </pre>
    </div>
  );
}
```

And there you have it a fully server side rendered component that will be cached for 60 seconds. Without the use of any third party libraries or the `useEffect` hook. This is a huge step forward for Next and I'm really excited to see what the future holds for it and how it will be used in the real world.

**Important Note**
As of right now 27.Oct.2022 you can not use one server side component inside of another without vscode throwing a type error at you. Since a server side component is basically a promise and a promise is not a valid JSX or TSX element. 

## Conclusion

Next.js is evolving and I'm really excited to see what the future holds for it. I'm really looking forward to the next release and I'm sure it will be a lot of fun to work with. I'm also really excited to see how the community will use these new features and what kind of new libraries will be built around them.



NEXT.JS is evolving


So how often do you fret that the react hook you are currently writing is never going to be re-used in your entire application except in one single lonely instance, or how about what should that hook even handle, what goes in that hook should you write a hook that depends on another hook or should both of those just be one mega hook that return an easy to destructure object that allows you or your team mates to access the hooks state or methods. Oh and then there's all those super useful hook libraries that are just one wbe search away where your ideal hook is just a quick copy paste away, should you use those or should you write your own? Well, I'm here to tell you that you should write your own, and I'm going to give you 5 tips to help you write better custom hooks.

## 1. Reusability is king 👑

The first thing you should ask yourself when writing a custom hook is "Will this hook be re-used in multiple places in my application?", or even does it have the potential to be re-used in multiple places. The answer is not as easy as you might think. Let's for example say that we have a custom hook named `useAuth` which handles your authentication logic such as logging the user in logging the user out, retrieving some information about the user and storing it somewhere easily accesible even if the user closes their browser etc. Your first thought might be well the user only ever needs to log in and log out once and the user info can just be stored in the application state, so clearly this is not an ideal candidate for a hook. 

However do you really want to vendor lock your auth to whatever application state library you're currently using. Do you really want to have to rewrite your auth logic over and over and over again for every single application you write? How about if the maintainer of that library decides to no longer maintain their codebase or even worse changes a core part of their codebase that breaks your auth logic. Do you really wanna trust someone else with your applications security? No, you don't.

Which is why a `useAuth` hook is an ideal candidate for a custom hook. But you may be wondering okay but the login and logout will still only ever be used once by the user so what's the point if it's not reusable. Now sure that part may not be all that reusable, however the part that retrieves the user info and stores it somewhere easily accessible is reusable. So you can have a `useAuth` hook that handles the login and logout and a `useUser` hook that handles the retrieval of the user info and storing it somewhere easily accessible. Furthermore you can call the `useUser` hook inside of the `useAuth` hook so that you can easily access the user info in the `useAuth` hook by simply returning the user info from the `useAuth` hook

### Example: 


```tsx
// useAuth.ts
import { useUser } from "./useUser"; // import the useUser hook

export const useAuth = () => {
  const { user, setUser, clearUser } = useUser(); 

  const login = async (email: string, password: string) => {
    // login logic goes here i.e via react-query or axios
    setUser(user);
  };

  const logout = async () => {
    // logout logic goes here i.e via react-query or axios
    clearUser(); // if you're storing your user info in local storage this method should delete it
  };

  // return the user and the login and logout methods
  return { user, login, logout };
};
```

## 2. Don't overcomplicate your hooks	

The second mistake I see people make is over engineer their custom hooks into these mega hooks that tackle too much functionallity at once. Optimally you'd want to follow the do one thing and do it well principle here. Meaning if you wanna write a hook that transforms your dates into nice human readable strings then you should not also try and cram in functionality that handles timezone logic or any of that stuff. You'd optimally have:
- `useRelativeDates` hook that handles transforming dates into human readable strings
- `useTimezone` hook that handles timezone logic, whatever it may be

Remember simplicity is key, but don't overdo it please. No need to have hooks that are 5 lines long and do nothing but return a value. Unless you have a very specific use case for that.

Everything in moderation grasshopper.

## 3. Plan out your hooks

Seriously I know I've gone into this whole thing in my other blog post [How Granular Should your Components be](/blog/how-granular-should-components-be)

But really, measure twice cut once. It's much easier to plan our a rough idea or concept of what your application and it's individual parts before you write a single line of code. This naturally comes with experience as well so if you're a fairly experienced developer maybe you don't need a planning phase for every single hook or component you write. But I'd consider myself fairly experienced and I can tell you with full certainty whenever I do take my time to plan out and scaffold my code before I write it I end up with much cleaner and maintainable code and I catch a lot of mistakes or weird trains of thought that I would have otherwise missed or would have mindlesly implemented while jamming out to some tunes.

## 4. Do search up other peoples hooks, don't copy paste

I know it's super tempting to just type in custom hook useWord into your favorite search engine, find the one that matches your use case the closest, copy paste it and be done with it. But that's not the right way to go about it. Firstly you're robbing yourself of a learning experience, secondly you can never be 100% sure the hook you've found is written in a way that suits your use case perfectly and you REALLY do not want to adjust your use case to fit the hook. That would be backwards. 

Instead do look up a hook that somebody else has created, read it through, study it and see which parts fit your use case and which do not. Use the parts that do fit and throw away the rest, add some of your own stuff to it and then you've got yourself a custom hook that you can be proud of and is truly your own and should fit your specific use case perfectly.

## 5. Don't be afraid to write a hook that depends on another hook

We already covered this in our first example, instead of writing a big mega hook that tackles a lot of functionality consider writing multiple smaller hooks that are very specific the word that comes after `use` should always perfectly describe what the hook does, e.g `useAuth`, `useUser`, `useLocalStorage`, `useAxios`, `useNewsApi` etc.

We've already covered that you can use one hook inside of another and then return the values of both hooks in an easily deconstructable object.

There is nothing wrong with taking this approach if anything it ties into the whole philosophy of react and react hooks. React is all about composition and reusability and so are react hooks. So don't be afraid to use one hook inside of another.

## Conclusion

I hope this post has helped you understand the importance of custom hooks and how to write them. I've been writing custom hooks for a while now and I can tell you with full certainty that they are one of the most powerful tools in your react developer toolbelt. They essentially allow us to abstract functionality away from our components into reusable functions that we can use in multiple places in our application. All of this without having to resort to any nasty **OOP**. 🤮

5 Essential Tips for Custom React Hooks


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)


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.


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.


TypeScript

React Query

NEXT.JS is evolving

5 Essential Tips for Custom React Hooks

How granular should components be?

How and when to use React Context

7 Steps to become a better react developer