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


Amongst us developers there's a strange but strong notion that the most optimal way to do anything is to do it the hard and "classical way". Be it mobile devs that insist that every app has to be written in their respective native language, game devs or software devs that insist garbage collection is horrible and makes you "lazy" as a developer or even web devs that insist you should stick to vanilla javascript and classic CSS and not even think about using something like tailwind or react. It's almost like a badge of honor that they prefer to do things the hard way, the "classical" way. But is it truly better and does it make you a better developer?

## Provide Value to the User

First and foremost our job is to provide value to the end user. Every single piece of software be it Backend or Frontend is at some point or another going to be used by someone. Even if they may not know they are consuming data from your API that cost you multiple weeks to build so that it delivers relevant data to the user at the right time. You are in essence providing that users with a certain value, the only thing that matters in that is that the value the user gets is greater than the value you put into it. 

Here's a good way to look at it, note that this is just one of many examples:

If you've spent 2 weeks building an API that will save 1.000 users even just 2h per week or provide them with just 2h of entertainment. You've essentially turned 2 weeks worth of work hours (roughly 80h) into 4.000h of entertainment or time saved. That's a pretty damn good deal and success metric if you ask me.

The end user will never know if you've used the most optimized way to create that API, they also won't care. Just like they won't care if your app is written in React, Next, Astro(best choice), they also won't care if you used tailwind or plain old CSS. They will only care if the app works and if it provides them with the value they are looking for.

## The Harder Way is not Always Better

If you've spent any time on any social media platform out there, you've probably encountered the type of person who will tell you that you shouldn't use X because it's the lazy or the easy way and should instead do it the hard way first so that you can "learn" from it and have a deeper understanding of the topic.

And that's fine, they're probably right to an extent. Heck I've been that person before. But I think that's also missing the point. If your goal is to learn then yes you probably should first attempt to understand the fundementals before you reach for the helper frameworks, libraries and tools, but if your goal is to get your product or your service out there to the public as soon as possible then you should absolutely use the tools that will help you get there faster. 

Your mission is to maximize the value you provide to the end user with minimal time investment. If you can do that with a tool that is easy to use and understand then you should absolutely use it. 

## Don't take it too far

So obviously we should always be super pragmatic and try to get as much stuff done with the right tools as fast as possible. However try and always be mindful that providing value to the user also means that you deliver a polished and well thought out product to them. Essentially don't get too hung up on making your code as efficient as possible or as optimized as possible as long as it does not affect the end experience of the user. To put it in simpler terms, make sure you deliver good products that are easy and fun to use and won't break every 5 minutes.

## Do take Pride in your Work

However that doesn't mean you shouldn't take pride in your work. I know we all enjoy getting a nice compliment or word of praise from our peers when we've done a good job. It verifies that our efforts have been worth it. However always keep in mind that your peers are not your target audience, your userbase or target userbase is. 

... Unless of course your peers are your target audience then definitely make sure to write clean and well thought out code that is easy to understand and maintain.

Which brings me to my next point

## Move Fast but don't Break Things

I never liked the motto: "Move Fast and Break Things". It fools the reader into believing that if you move fast or deliver your products fast that you are required to break some things along the way. That's not true. We live in a time where we are as developers spoiled for choice with tools that can help us move fast and deliver quality products. We got: Astro, React, Next.js, Svelte, Tailwind, Fastify, Gastby, tRPC, Supabase, Firebase, Railways, MongoDB and so on and so on.

Don't be afraid to use the damn tools that people have built for you. You are trying to convert you time investment into value for the end user and these tools likewise were built with a time investment from their developers to provide value to you. Use them and use them well.

Too often I see twitter threads still berating people for using tailwind by spouting the same old argument that people should just "learn" css. Trust me if someone is using tailwind to any productive extent, they probably know CSS pretty well, better than most.

Same with tools like React, Next, Astro, Svelte, etc. If you're using them you probably know vanilla javascript pretty well. You probably know how to write a simple web app without any of these tools. But developers choose to use these tools because they can help them move faster and deliver better products to their users.

So in essence don't move fast and break things. **Move fast and deliver instead**.

## Conclusion

So in conclusion, don't be afraid to use the tools that will help you get your job done faster and more efficiently. But also don't be afraid to take pride in your work and make sure you deliver a good product to your users.



Harder does not mean better


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


Open source means that anyone can see your work, judge it, judge you or even worse copy your amazing idea, take all the credit and make a lot of money off of your hard work and effort. Why would you ever wanna open source anything? Well, there are a lot of reasons why you should open source your projects. I will try to explain some of them in this post.

## Community Support

One of the biggest benefits of making your work open source is that you'll have access to a large community of people that can help you with your project. They will give you feedback, help you with bugs, provide help with new features, sometimes even directly have a feature PR ready with their issue submission and so on. Usually the kinds of people that want to help you with your projects are users of your product or service. They are the ones that will benefit from your work and they are the ones that will use it. So they are the ones that will be the most interested in helping you with your project.

Which ties nicely into my next point which is

## Open Source can Turbocharge your Learning

Because you will work with others on your project. You'll also get to learn a lot from others. You may be a senior software developer with countless years and successful deployments under your belt, but you can still learn a lot from even the most junior of developers out there. Perhaps someone would tackle a certain problem differently than you, maybe not better maybe not worse, but differently and that may learn from them.

And that's just learning from the submissions of others, then there's the learning from feature requests, bug reports, discussions and so on. Which can give you a substantially better understanding of your users and their needs.

And on that note

## Open Source can Help you Understand your Users Better

One of the biggest pain points of any software developer is marketing or user research. Most don't find enjoyment in these activities. However when your open source project gains popularity you will get a lot of feedback from your users... a lot of feedback. Which will help you understand your users and their needs better. This will of course lead to a more focused and streamlined product/service. 

You don't wanna deliver a swiss army knife to your users when they're really just asking for a toothpick. 

Of course to get to that point you'll have to do a bit of networking and "marketing" yourself. Which leads me to

## Open Source can Help you Network

If you contribute to open source, you'll have to interact with others. If you maintain an open source project, you will have to interact with others. How often do you get the chance to work on the same project as a FAANG engineer? Or the creator of your favorite framework/library. Well with open source you can and as you can imagine, that's a great opportunity to network with people from different backgrounds and skill levels. Sometimes you may even build a lasting friendship with someone you've never met in real life.

Which ties in with

## Collaboration can Fuel Innovation

When you meet people from the open source community and find out about their passions and their passion projects, you may find that your skill sets and interests compliment each other. You may find that you can work together on a project that you both find interesting. And that's a great way to fuel innovation. 

The best ideas and the best projects usually come from two or more likeminded weirdos with a unique interest meeting.

## Better Code

Now this one is pretty far out there, but hear me out okay. I firmly believe that if you open source your code, you will instinctively write better code. 

**Why thought?**

Well it's simple really, everytime you push a commit to your open source project, you're essentially putting your name on it. You're making it a part of your online presence, your identity essentially. 
Now obviously you shouldn't stress too much about being judged by others. To hell with that screw what they think you do you. But we're all human and we all want our creative work to be appreciated and to be seen in a positive light.

So no matter who you are, I'm certain that if you open source your code, you will write better code.

## Financial Reasons

Open source and is a part of the FOSS acronym (Free and **Open Source** Software) and a lot of people hear the word free and think, well there's no money to be made there so why even bother.

However seriously ever heard of Google, Spotify, Facebook? They all offer their services for free and make more money than most B2B enterprise grade software companies.

Now I know bad argument not everyone can be google or spotify, but open source does not mean free. You can earn a good amount of money by doing nothing but open source. In fact you can even earn a living by doing nothing but open source.

If it's your own project this would come in a form of sponsorship or "backing" for your projects, basically users or companies that use your project may want to support you financially so that they may keep using your product or service. Sometimes they may even wish to "donate" so that you can focus on a certain feature that they want to see implemented for their use case.

There are also websites where companies can post "bounties" on open source issues and if someone solves the issue they get paid.

And of course there's the good old fashioned way of selling your product or service. Or even a part of it as a SaaS offering.

Basically you can offer the main part of your product or service for free but charge a fee for certain bundles of features or services. This would be the Spotify or youtube model, they both offer their main service for free but allow you to pay for a more premium experience.

## Backup

This is also a bit of a weird one. But open sourcing your code is a form of backup. If your workstation crashes, harddrive fails, or you simply lose your 2FA code, you can still simply clone your own repository and get back to work. Since after all it is public.

## Can Help you Land a Job

A lot of really good companies such as Mozilla, Microsoft, Google and so on will look at your open source contributions when you apply to work for them and will take that into consideration when deciding whether or not to hire you.

It doesn't even have to be super advanced leet code type stuff. Even just helping out with a small bug or feature, amending documentation, fixing typos, styling etc. can go a long way.

## Conclusion
So there you have it 9 compelling reasons why you should open source your projects. I hope you enjoyed this post and that it helped you in some way. 

## Disclaimer
Now I do have to be fully honest and transparent here, I did make open source sound very positive in this article and many might read it and thing. Wow open source sure is an amazing thing and everyone should do it. However just like in every other thing in life there are also some downsides to open source. One amazing example of the darker side of open source can be seen in the following video by Fireship

[![Fireship - The Dark Side of Open Source](https://img.youtube.com/vi/R6S-b_k-ZKY/0.jpg)](https://www.youtube.com/watch?v=R6S-b_k-ZKY)

Open Source your Projects


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.



React Just Got Even More Awesome


Tired of writing the same auth code over and over again every time you start a new project? Let's build a simple authentication system using React Context. This way we can easily reuse it in all our projects, completely independat of the state management library we use. 

## Why React Context and not Redux, recoil, zustand...

React Context is a very powerful tool, but it's not the only tool in the shed. There are a lot of other state management libraries out there that can do the same thing. So why use React Context? Well, it's simple really. React Context is built into React, it's a native feature. This means that we don't need to install any third party libraries to use it. This also means that we can use it in any React project, even if we're not using any other state management library.

In fact handling auth is a damn near perfect candidate for react context, because by it's very nature it belongs in a global application state and we don't expect it to change very often.

## What we're going to build

We're going to build a very simple authentication system with react context and react hooks that will allow us to: 
- Store the user's information in the context and local storage
- Check if the user is logged in
- clear the user's information from the context and local storage
- retrieve the user's information from the context and local storage

**WE WILL NOT** build a fully fledged authentication system with login, logout, registration, etc. We will only build the frontend part, meanig the part that will allow our frontend to know if the user is logged in or not and react accordingly, meaning we will **not**:
- send the user's credentials to the backend
- verify the user's credentials
- store the user's credentials in the backend

I'll assume you're already familiar with React and TypeScript, I'll also assume you've already have a react or next.js app set up. If you don't, use [create-react-app](https://create-react-app.dev/), [create-next-app](https://nextjs.org/docs/api-reference/create-next-app) or even [t3-app](https://github.com/t3-oss/create-t3-app) to get started.


## Step 1: React Hooks

Let's start off by creating a couple of custom hooks that we'll require for out auth system, first create a directory called `hooks` in your `src` directory then create the following files in there:
- `useAuth.ts`
- `useUser.ts`
- `useLocalStorage.ts`
  
### useLocalStorage.ts

This hook will allow us to easily store and retrieve data from localStorage. It's a very simple hook, but it's a good idea to keep it in a separate file so we can reuse it in other parts of our application.

```tsx
import { useState } from 'react';

export const useLocalStorage = () => {
  const [value, setValue] = useState<string | null>(null);

  const setItem = (key: string, value: string) => {
    localStorage.setItem(key, value);
    setValue(value);
  };

  
  const getItem = (key: string) => {
    const value = localStorage.getItem(key);
    setValue(value);
    return value;
  };

  const removeItem = (key: string) => {
    localStorage.removeItem(key);
    setValue(null);
  };

  return { value, setItem, getItem, removeItem };
};
```

### useUser.ts

This hook will store the user in our context and localStorage.

```tsx
import { useContext } from 'react';
import { AuthContext } from '../context/AuthContext';
import { useLocalStorage } from './useLocalStorage';

export interface User {
  id: string;
  name: string;
  email: string;
  authToken?: string;
}

export const useUser = () => {
  const { user, setUser } = useContext(AuthContext);
  const { setItem } = useLocalStorage();

  const addUser = (user: User) => {
    setUser(user);
    setItem('user', JSON.stringify(user));
  };

  const removeUser = () => {
    setUser(null);
    setItem('user', '');
  };

  return { user, login, logout };
};
```

### useAuth.ts

This is the hook where it all comes together. This react hook will be responsible for checking if the user is logged in or not, and if they are, it will return the user object. If the user is not logged in, it will return null.
We'll also expose a `login` and `logout` function that we can use to log in and log out the user.

```tsx
import { useEffect } from 'react';
import { useUser } from './useUser';
import { useLocalStorage } from './useLocalStorage';

export const useAuth = () => {
  const { user, addUser, removeUser } = useUser();
  const { getItem } = useLocalStorage();

  useEffect(() => {
    const user = getItem('user');
    if (user) {
      addUser(JSON.parse(user));
    }
  }, []);

  const login = (user: User) => {
    addUser(user);
  };

  const logout = () => {
    removeUser();
  };

  return { user, login, logout };
};
```

## Step 2: React Context

Now that we have our hooks ready, let's create our context. Create a directory called `context` in your `src` directory and create a file called `AuthContext.tsx` in it.

```tsx
import { createContext } from 'react';
import { User } from '../hooks/useUser';

interface AuthContext {
  user: User | null;
  setUser: (user: User | null) => void;
}

export const AuthContext = createContext<AuthContext>({
  user: null,
  setUser: () => {},
});
```

## Step 3: Wrap your app in the context provider

Now that we have our context ready, let's wrap our app in it. Open your `App.tsx` file and wrap your app in the context provider.

```tsx
import { AuthContext } from './context/AuthContext';
import { useAuth } from './hooks/useAuth';

const App = () => {
  const { user, login, logout } = useAuth();

  return (
    <AuthContext.Provider value={{ user, setUser }}>
      <div className="App">
        <h1>Hello CodeSandbox</h1>
        <h2>Start editing to see some magic happen!</h2>
      </div>
    </AuthContext.Provider>
  );
};

export default App;
```

## Step 4: Create a login page

Now that we have our context ready, let's create a login page. Create a directory called `pages` in your `src` directory and create a file called `login.tsx` in it.

```tsx
import { useAuth } from '../hooks/useAuth';

const Login = () => {
  const { login } = useAuth();

  const handleLogin = () => {
    login({
      id: '1',
      name: 'John Doe',
      email: 'john.doe@email.com',
    });
  };

  return (
    <div>
      <h1>Login</h1>
      <button onClick={handleLogin}>Login</button>
    </div>
  );
};

export default Login;
```

## Step 5: Create a logout button

Awesome now we have a login page all there's missing is a way to log out, let's create a logout button. Create a file called `LogoutButton.tsx` in your `src` directory.

```tsx
import { useAuth } from '../hooks/useAuth';

const LogoutButton = () => {
  const { logout } = useAuth();

  return <button onClick={logout}>Logout</button>;
};

export default LogoutButton;
```

## Further steps

Now that we have our helpful hooks and context ready all we need to do is use them in our application, for example we can call our `useAuth` hook in our `App.tsx` to check if the user is logged in or not, if not we can redirect the user to the login page. We can also conditionally render the logout button based on whether the user is logged in or not.

All of this is completely independant from any and all state management libraries.


### A note on localStorage

I've used localStorage in this example, but you can use any other storage mechanism you want. For example, you can use cookies The only thing that matters is that you store the user object in a way that you can retrieve it later.
Additionally you should also probably encrypt the user object before storing it in localStorage, but that's out of the scope of this article. Also you should probably allow the user select if they wish to persist their login after leaving the page or not.

**IMPORTANT** This is not a secure way to store user data, it's just a simple example to show how you can use react hooks to create a simple authentication system. You should optimally use a secure authentication system like JWT or OAuth, but that's out of the scope of this article.

## Conclusion

In this article we've learned how to create a simple authentication system using react hooks and context. We've also learned how to persist the user object in localStorage so that the user doesn't have to log in every time they visit the page.


Use React Context for Auth




## What is the Tao of Git?

The tao or "the path" of git is a set of guiding principles that will help you understand the complex nature of git and how to use it properly. It's what separates a git user from a git master. Follow the tao and you will in time achieve great things, through your knowledge of git.

## What is Git ?

Git is a version control system, much like time is ever flowing, your code is ever changing. Git is a tool that allows you to keep track of all the changes that were and all the changes that shall be. Understanding git is understanding the nature of time and the nature of change. Git is the path to enlightenment. 

> You can not change the past, unless you use git. Then you totally can
> 
> - [Dayvi Schuster](https://twitter.com/dayvsterdev/status/1578425436605800451)

## Of Paths and Branches

Much like in terminator there are multiple timelines happening at the same time with multiple different versions of the same events. In git there are multiple branches keeping track of different versions of the same code. This is what allows a student of git to work on multiple features at the same time without them polluting each other. You will only have to manually merge the changes when the same file is changed in both branches. Do not try to merge branches that have nothing to do with each other, this will only lead to pain and suffering.

In this most students of git agreed upon a holy trinity of branches, the `main` branch, the `develop` branch and the `staging` branch. There's also the `hotfix` and `feature` branches but we'll get to those later.

### The Main Branch

The `main` branch is the branch that must always stay stable, no work shall be done on the main branch, the only changes permitted in the main branch should happen via a **pull request** from `staging` to `main`. The main branch will be automatically deployed to production for all to see and marvel at. The main branch is the most sacred of all branches, it is the branch that must never be broken.

### The Staging Branch

The `staging` branch is the branch which will be available as a staging ground for future changes/features this branch should always strive to be stable, but it's okay if it's not. The features which developers merge from `dev` to `staging` should be tested by the QA team before they are merged to `main`. The staging branch is the branch that will be deployed to a staging environment for testing. Only upon approval of the QA team will a pull request be permitted to pass from `staging` to `main`.

Do not skip this step, for it is the most important step in the process. If you skip this step you will be cursed with a thousand years of bad luck. And also it'll be a serious pain to fix later. Like weekend work and stuff. You don't want that.

### The Develop Branch

The chaotic branch or the branch of change also called the `dev` or `development` **NEVER** `develop` branch, seriously who calls it the `develop` branch, either abbreviate it fully to `dev` or don't. Anyhow upon this branch all development work shall be done and merged into. This branch should be decorated with as many unit tests, integration tests and e2e tests as possible. The `dev` branch is the branch that will be deployed to a development environment for testing. If the automated tests pass then the spirits have given you permission to merge to `staging`. But also like tag your team lead or co-worker in your pull-request so they can review it. The spirits can't do all the work.

### The Hotfix and Feature Branches

These are the branches that developers shall create upon recieving a task or bug report from their product owner or team lead. Upon recieving your sacred task you shall create a branch with the name of the task or bug report. This branch shall be created from the `dev` branch. Upon completion of the task or bug fix you shall merge your branch into `dev` and then `staging` and then `main`. If you are a good student of git you will also delete your branch after merging it into `main`. If you are a bad student of git you will leave your branch hanging around for all eternity. This of course will anger the spirits and your team lead or co-worker will have to delete it for you, which may really annoy them. So don't do that.

## Of Commits and Commit Messages

Every developer must in time commit and they must do so often, upon committing they are tasked with providing a commit message. The commit message is the most important part of the commit, it is the message that the developer wishes to convey with their work, it is a short sentance that explains their hours, days or at times weeks of hard labour and effort. The commit message should be written in the imperative mood, it should be short and to the point. It should be written in the present tense and it should be written in the active voice. The commit message should be written in the following format:

```bash
<type>(<scope>): <subject>
```

The type of the commit should be one of the following: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`. The scope of the commit should be the name of the file or folder that was changed. The subject of the commit should be a short description of the changes made. 

For example:

```md
feat(data/posts): add new post about the tao of git
```

If the labour of the developer spanned multiple suns and moons then they should provide a longer description of their work in the body of the commit message. to do so they should invoke the following command `git commit -m "feat(data/posts): short description" -m "long description"`. The long description should be written well and understandable by fellow developers. This is an act of kindness and will be greately appreciated by your fellow developers, especially your team lead or whoever is responsible for documentation. 

## Of Merges and Merge Conflicts

Merges are the most sacred of all git rituals, they are the most important part of the git tao. Merges are the way in which developers can apply the changes they have done to the codebase in one branch to another branch. Through this ritual the developer can apply the changes they have made to the `dev` branch to the `staging` branch and then to the `main` branch. But sometimes the fates are not kind and merge conflicts may arise. Upon spotting a merge conflict the developer himself or herself is responsible for resolving the merge conflict of their Pull Request, only upon resolution of the merge conflict will the pull request be allowed to pass. 

## Of Pull Requests and Reviews

When a developer is confident that their labour/task has been acomplished they may request a `pull` of their work into another branch or a `pull request`. Upon creating a pull request the developer must request a review from their team lead or co-worker. The team lead or co-worker is responsible for reviewing the pull request and ensuring that the developer has done their work properly. If the team lead or co-worker is not satisfied with the work of the developer they may request changes to the pull request. The developer is responsible for applying the requested changes to the pull request. Only upon approval of the team lead or co-worker will the pull request be allowed to pass.

Be careful when doing a code-review, to do a good code-review one must separate themselves from their ego. Remember it's not about you there is only the code. You or your company may have certain rules or guidelines in place for deciding what consistutes as clean, readable and maintainable code. Make sure that you judge only the code and not the developer who submitted the code. They are not up for judgement, a code review is a place of learning and growth. If you find yourself judging the developer then you are doing it wrong. 

Make sure you allow the reviewee to explain their thought process and reserve judgement, sometimes even a master can learn from a student. Their thought process or how they tackle a problem may surprise you and give you a new perspective. If you fundamentally disagree and know that their code could be improved then explain it in a kind and informative manner and provide a suggestion for improvement, together you may find a solution that is better than either of you could have come up with on your own. This is the way of the code-review.

## Of Lesser Known Commands

Much like a painter does not know all the colours in the world, a developer does not know all the commands in git. I will not claim I can teach you all of them for that would be impossible. But I can teach you some of them.
Here's a list of some lesser known commands that you may find useful as I do:

### Worktree

```bash
git worktree add <path> <branch>
```

A worktree is a way to have multiple branches checked out at the same time. This is useful if you want to work on multiple branches at the same time. For example if you want to work on a feature branch and a bugfix branch at the same time. You can do so by creating a worktree for each branch.

### Cherry Pick

```bash
git cherry-pick <commit>
```

Much like you would pick only the best looking cherries from a tree of cherries, you may cherry pick a single commit from another branch and apply it to your current branch.

**NOTE** This will create a new commit with the same commit message as the cherry picked commit. If you want to change the commit message you can do so by using the `--no-commit` flag and then using the `git commit --amend` command.

### Git Stash

```bash
git stash
```

Sometimes a student of git may get distracted or sidetracked but does not wish to use a worktree, in this case they may use the git stash command. This command will save your current work and allow you to switch between branches without losing your work. You can then apply your work to another branch by using the `git stash apply` command.

### Git diff and Git diff --staged

```bash
git diff
```

```bash
git diff --staged
```

These commands are useful for seeing the changes you have made to your codebase. The `git diff` command will show you the changes you have made to your codebase that have not been staged. The `git diff --staged` command will show you the changes you have made to your codebase that have been staged.

### Git blame

```bash
git blame <file>
```

Sometimes as a developer you may not recognize a piece of code as your own, this is okay do not be alarmed, you have `git blame` at your disposal. Invoke this command and it will tell you where the line of code in front of you came from and who created it. This is useful for when you are trying to figure out why a piece of code is the way it is. Or when you're really lost and need guidance from the author of the code. 

### Git log

```bash
git log
```

Invoke this command if you wish to have the history of your current branch presented to you, upon invoking this command a list of commits will be presented to you from those that came before to those that came after. Basically look you get a list of commits, what more do you want from me?

## Conclusion

I hope you have enjoyed this journey into the tao of git. I hope you have learned something new and that you will be able to apply it to your own work. I hope you will be able to use this knowledge to become a better developer and a better person.



The Tao of Git


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.


7 Steps to become a better react developer


## What we are going to be building?

In this short tutorial I will guide you through building our very own URL shortener similar to bit.ly and other such services. The language we'll be using will be **C#** with **.NET core 2.2**, so make sure you have at the very least intermediate knowledge of C#. I'll make sure to cover the theory and some quick and simple solutions in the tutorial below, so non C# developers are welcome to join us as well.

## The result

The source code for this project is readily available over at [Github](https://github.com/arctekdev/nixfox.de)

## The Setup

First thing is, we'll want to set up our simple **ASP.NET API** project. We can do this either directly through Visual Studio, in this case **Visual Studio 2017**. Simply head over to `File > New > Project` make sure to select **ASP.NET Web Application** from the selection menu, name your project whatever name you want down in the name field and then click Ok. After that you'll be presented with a variety of templates. What you're gonna wanna do is select **Web Application(Model-View-Controller)**, then uncheck Enable Docker Support and uncheck Configure for HTTPS. Make sure that Authentication is set to **No Authentication** and whenever you're ready click OK.

![the result](https://i.imgur.com/y7hLomU.png)

Your settings should look a little bit like this.

You may also set everything up using the `dotnet new` command. In which case simply open up the command window or terminal in your desired project directory and run `dotnet new mvc`, this should set everything up for you.

the next thing you wanna do is install [LiteDB](https://www.litedb.org/)

## Let's get started

The very first thing I always like to do is clean up some of the useless default code that Visual Studio sets up for me. Then I head over to create a new controller and call it `HomeController.cs`. Once the controller is good and ready I like to add the endpoints that I expect to use. So basically for a URL Shortener we'll need:

- a default _"index"_ endpoint that delivers our webpage to the user **http method: GET**
- an endpoint that received the URL the user wishes to shorten and returns the shortened version **http method POST**
- a redirect endpoint that gets redirects the user from the shortened URL to the original URL **http method GET**

Pretty simple stuff right there. Our controller should now look something like this:

```csharp
using System.Net.Http;
using System;
using System.Linq;
using Microsoft.AspNetCore.Mvc;
using nixfox.App;


namespace nixfox.Controllers
{
	// This will be needed later in the PostURL() method
	public class URLResponse{
		public string url { get; set; }
		public string status { get; set; }
		public string token { get; set; }
	}
	public class HomeController : Controller{
    	// Our index Route
		[HttpGet, Route("/")]
		public IActionResult Index() {
			return View();
		}

		// Our URL shorten route
		[HttpPost, Route("/")]
		public IActionResult PostURL([FromBody] string url) {
			throw new NotImplementedException();
		}

        // Our Redirect route
		[HttpGet, Route("/{token}")]
		public IActionResult NixRedirect([FromRoute] string token) {
			throw new NotImplementedException();

		}
	}
}
```

That will serve as the basic skeleton of our HomeController.

## Create a razor view

Go down to your **Views** folder and create a new directory named `Home` in that directory create a new file named `index.cshtml`. Now you could simply stuff all your HTML + Razor code in that one .cshtml file and then serve it to the user. but I like to stay a bit more organized so what I like to do is:

Create a new partial for the header of the page by creating a new .cshtml file named `header.cshtml` in the `partials` directory. Then in shared you'll want to create a `_layout.cshtml` file which will serve as the main layout of your view.

### \_layout.cshtml

```html
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>nixfox | shorten your URLs and links in style</title>

    <link
      href="https://fonts.googleapis.com/css?family=Open+Sans&display=swap"
      rel="stylesheet"
    />
    <link rel="stylesheet" href="css/site.css" />
  </head>
  <body>
    @await Html.PartialAsync("~/Views/Partials/Header.cshtml")
    <section id="main-wrapper">@RenderBody()</section>

    <script src="~/js/site.js"></script>
  </body>
</html>
```

### header.cshtml

```html
<header id="main-header">
  <section>
    <h1>nixfox.de</h1>
    <h2>a super light and friendly url shortener</h2>
  </section>
</header>
```

### Home/index.cshtml

```html
<div class="shortener-form-wrap">
  <section class="shortener-form">
    <h2>Enter your link below and get it shortened, nice and easy.</h2>
    <div class="input-wrap">
      <input
        type="text"
        name="url"
        id="urlshort"
        placeholder="Shorten your URL"
      /><button id="submit">Shorten</button>
    </div>
    <div class="resp-area inactive" id="resp-area"></div>
  </section>
</div>
```

Now you might be wondering, ain't that a lot of work for something that simple? Yes, absolutely, but trust me it's worth it when you decide to eventually extend your web application to have everything split up like that. Imagine if you'll later decide ''oh wait I should probably add a terms of service page, or an about page, or a documentation page etc.''. It will be a lot easier to not have to create a whole new HTML boilerplate page every time you wish to create a subpage like that. Plus there's a fair bit of magic .NET does when serving reusable files, that shows a slight improvement on performance. Granted it won't be noticeable on a small scale application like this but it's definitely good practice.

## Onward!

With that out of the way feel free to style your page as you see fit. The important part is that it contains this input field

```html
<input
  type="text"
  name="url"
  id="urlshort"
  placeholder="Shorten your URL"
/><button id="submit">Shorten</button>
```

## The meat of the project

The main part the actual URL shortener is fairly easy and short(badum tss 🥁 💥). Your first instinct might be to simply hash the original URL and use that as a token, that would of course provide a lot of uniqueness, however short hashing functions are often unreliable and sooner or later you'll run into the [birthday paradox](https://en.wikipedia.org/wiki/Birthday_problem) problem, which is not half as fun as it sounds.

![terrible birthday](https://media.giphy.com/media/3o6MbojLxJuz4IByQ8/giphy.gif)

Right so **how to guarantee a unique token**, really simple, we resort back to good old randomization. The plan is to generate a string of random characters between 2 and 6 characters in length. Using the full English alphabet plus all numerals from 0-9 that gives us 62 available characters, meaning we have:

`(62^2) + (62^3) + (62^4) + (62^5) + (62^6)` possible unique tokens which equals: \`57 billion 731 million 386 thousand 924´

That'll do pig... that'll do.

![babe the pig](https://media.giphy.com/media/f50TuQCGUAYH6/giphy.gif)

Basically every single person in the world could without a problem shorten 8 URLs with us, every... single... one of them. That of course is an impossible scenario.

## The Code

```csharp
using LiteDB;
using System;
using System.Linq;

namespace nixfox.App{
	public class NixURL{
		public Guid ID { get; set; }
		public string URL { get; set; }
		public string ShortenedURL { get; set; }
		public string Token { get; set; }
		public int Clicked { get; set; } = 0;
		public DateTime Created { get; set; } = DateTime.Now;
	}

	public class Shortener{
		public string Token { get; set; }
		private NixURL biturl;
		// The method with which we generate the token
		private Shortener GenerateToken() {
			string urlsafe = string.Empty;
			Enumerable.Range(48, 75)
              .Where(i => i < 58 || i > 64 && i < 91 || i > 96)
              .OrderBy(o => new Random().Next())
              .ToList()
              .ForEach(i => urlsafe += Convert.ToChar(i)); // Store each char into urlsafe
			Token = urlsafe.Substring(new Random().Next(0, urlsafe.Length), new Random().Next(2, 6));
			return this;
		}
		public Shortener(string url) {
			var db = new LiteDatabase("Data/Urls.db");
			var urls = db.GetCollection<NixURL>();
            // While the token exists in our LiteDB we generate a new one
            // It basically means that if a token already exists we simply generate a new one
			while (urls.Exists(u => u.Token == GenerateToken().Token)) ;
            // Store the values in the NixURL model
			biturl = new NixURL() {
                Token = Token,
                URL = url,
                ShortenedURL = new NixConf().Config.BASE_URL + Token
            };
			if (urls.Exists(u => u.URL == url))
				throw new Exception("URL already exists");
            // Save the NixURL model to  the DB
			urls.Insert(biturl);
		}
	}
}
```

Confused? Don't be, I'll explain everything.

### The database model

```csharp
	public class NixURL{
		public Guid ID { get; set; }
		public string URL { get; set; }
		public string ShortenedURL { get; set; }
		public string Token { get; set; }
		public int Clicked { get; set; } = 0;
		public DateTime Created { get; set; } = DateTime.Now;
	}
```

This simply represents a single entry in our database. Each column in our DB will have the following fields:

- string URL
- string ShortenedURL
- string Token
- int Clicked
- DateTime Created which will default to the DateTime.Now

All fairly simple and self explanatory.

### Token generator

```csharp
		private Shortener GenerateToken() {
			string urlsafe = string.Empty;
			Enumerable.Range(48, 75)
              .Where(i => i < 58 || i > 64 && i < 91 || i > 96)
              .OrderBy(o => new Random().Next())
              .ToList()
              .ForEach(i => urlsafe += Convert.ToChar(i)); // Store each char into urlsafe
			Token = urlsafe.Substring(new Random().Next(0, urlsafe.Length), new Random().Next(2, 6));
			return this;
		}
```

Now this is where I like to complicate things a tiny bit and probably owe you an explanation or two. So first I create a string which will carry all of our URL safe characters and assign it a value of `string.Empty`.

After that comes the fun part, what we know about characters is that they can be represented using numerical values, so I decided to simply loop through the ranges of numerical values where the URL safe characters are located and add that to a string of URL safe characters programmatically. There is nothing stopping you from storing them as:

```csharp

string  urlsafe = "AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz0123456789"
```

But that's boring isn't it... you could also simply use a for loop instead of **LINQ**. Personally I like using LINQ and it does seem like the perfect job for link and opportunity for you to practice your LINQ skills.

After I generated my string of URL safe chars I simply call

```csharp

urlsafe.Substring(new  Random().Next(0, urlsafe.Length), new  Random().Next(2, 6));
```

Store it to the class member named `Token` and return `this`, which allows us to chain methods (more on that later).

To generate a random string between 2 and 6 (at random) characters long. **double randomization WOO**

![WOO](https://media.giphy.com/media/yUI3a7RwLhOFy/giphy.gif)

And just like that we're generating our random token.

### Shortener

```csharp
		public Shortener(string url) {
			var db = new LiteDatabase("Data/Urls.db");
			var urls = db.GetCollection<NixURL>();
            // While the token exists in our LiteDB we generate a new one
            // It basically means that if a token already exists we simply generate a new one
			while (urls.Exists(u => u.Token == GenerateToken().Token)) ;
            // Store the values in the NixURL model
			biturl = new NixURL() {
                Token = Token,
                URL = url,
                ShortenedURL = new NixConf().Config.BASE_URL + Token
            };
			if (urls.Exists(u => u.URL == url))
				throw new Exception("URL already exists");
            // Save the NixURL model to  the DB
			urls.Insert(biturl);
		}
```

Now all there's left for us to do is "connect" to the database and store our token with the URL it points to and the rest of the relevant data. Make sure to follow the code above to ensure you don't store duplicate tokens.

## The Return Of the HomeController.cs

Now we come back to our HomeController.cs and extend our endpoints

```csharp
[HttpPost, Route("/")]
public IActionResult PostURL([FromBody] string url) {
	// Connect to the database
    var DB = LiteDB.LiteDatabase("Data/Urls.db").GetCollection < NixURL > ();
    try {
    	// If the url does not contain HTTP prefix it with it
        if (!url.Contains("http")) {
            url = "http://" + url;
        }
        // check if the shortened URL already exists within our database
        if (new DB.Exists(u => u.ShortenedURL == url)) {
            Response.StatusCode = 405;
            return Json(new URLResponse() {
                url = url, status = "already shortened", token = null
            });
        }
        // Shorten the URL and return the token as a json string
        Shortener shortURL = new Shortener(url);
        return Json(shortURL.Token);
    // Catch and react to exceptions
    } catch (Exception ex) {
        if (ex.Message == "URL already exists") {
            Response.StatusCode = 400;
            return Json(new URLResponse() {
                url = url,
                    status = "URL already exists",
                    token = DB.Find(u => u.URL == url).FirstOrDefault().Token
            });
        }
        throw new Exception(ex.Message);
    }
}
```

First let's start with our **PostURL** endpoint. As you can clearly see much has changed and all is explained in the comments of the actual code. It's very important for redirection purposes to ensure every URL stored in your database is prefixed with HTTP:// at least, otherwise when ASP.NET tried to redirect the user without there being a HTTP:// it will attempt to redirect the user to another endpoint on the server. So in this case, say you store www.google.com without HTTP, without this check my nixfox.de shortener would attempt to redirect the user to https://nixfox.de/www.google.com which would naturally result in an error.

You also have to make damn sure that the URL the user wishes to shorten does not already exist in the database, otherwise a potential troublemaker might shortned a URL take the shortened URL, shorten it again and again and so on building a chain of redirects which would naturally slow down our server substantially.

After you preformed all your important checks which you can freely add to your project yourself. Shorten the URL by calling `new Shortener(url)` and return the token as a JSON string.

### The redirect

```csharp
[HttpGet, Route("/{token}")]
public IActionResult NixRedirect([FromRoute] string token) {
    return Redirect(
    	new LiteDB.LiteDatabase("Data/Urls.db")
        .GetCollection < NixURL > ()
        .FindOne(u => u.Token == token).URL
    );
}

private string FindRedirect(string url) {
    string result = string.Empty;
    using(var client = new HttpClient()) {
        var response = client.GetAsync(url).Result;
        if (response.IsSuccessStatusCode) {
            result = response.Headers.Location.ToString();
        }
    }
    return result;
}
```

This is possibly the simplest endpoint we've got as it simply takes the token finds it in the database and finally redirects the user to the URL associated with the token, and that's all there is to it.

## The final part the Javascript

All you have to do now is get the onclick event of your shorten button, post the URL from the input field to the correct end point and you'll get your redirect token back in the form of a JSON string.

You can easily do this by:

```csharp
var submitBtn = document.querySelector("#submit");
var urlInput = document.querySelector("#urlshort");
submitBtn.onclick = function (ev) {
    let url = urlInput.value;
    fetch("/", {
            method: "POST",
            body: JSON.stringify(url),
            headers: {
                'Content-Type': 'application/json'
            }
        }).then(res => res.json())
        .then(response => {
                console.log(response);
            }
        }
}
```

Sending a simple fetch POST request to the "/" endpoint with the desired URL. Which will return the redirect token in the `console.log`, feel free to change that.

## Improvement potential

Obviously this application is not perfect and has a lot of improvement potential such as:

- Precalculating tokens to prevent time outing an unlucky user that gets a non-unique token too many times
- Freeing up tokens based of off last activity
- A click counter for the tokens in question
- more validation both client and serverside
- and much much more.

Hope you had fun!


Make a URL Shortener in C#


## Well is .NET still worth learning in 2019?

The short and boring answer would be, yes. But I assume you're not here for a quick and boring answer, are you? You're probably
here because you are considering which language to learn in 2019. Or maybe you're a greenhorn and would like to dip your toes into
the vast waters of programming. Well in this article I'm going to try and convince you to give C# a try.

## Exciting time for C#

Just a few weeks ago we were figuratively blown away by some of Microsoft's announcements regarding windows, .NET and C#. Chief among them
being:

- **Fluid** web **framework** that aims to make the web a more productive and interactive place
- **Windows terminal** inspired by it's linux counterparts, aims to improve developer efficiency
- a full linux kernel within Windows with **WSL 2.0**
- **KEDA** and event driven scaling extension for Kubernetes
- **IOT Plug and Play** does it need more hype than that?
- Machine learning for .NET named **ML .NET 1.0**
- and much much more

in short, it's an exciting time to be a .NET developer whether you already have a background in coding or you are just entering the field.
A world of opportunity career and otherwise awaits you.

## Game Development with .NET

C# has always been a favorite of game developers worldwide, and it strikes a good balance between performance, low level, oop and easy of coding
with some syntactic sugar gently sprinkled in 🥁 💥 . Now here's a fun statistic almost half the games are made using Unity 3D

![unity statistic](https://cdn0.tnwcdn.com/wp-content/blogs.dir/1/files/2016/03/Picture1.png)

Now I am fully aware Unity 3D supports both Javascript and C# as their programming languages. However, one can assume a vast majority of devs
opts for the language that sacrifices less performance, which would, of course, be C#.

With Unity 3D you can create anything from Mobile, PC, and even VR games. So if you're looking to make your future in game development
look no further than C#.

## Rich Job Market

.NET has been a highly sought after skill for well over a decade now. Just a quick search for .NET jobs on Monster.com gives us a staggering
result of `30155 Jobs Found`. While average salary statistics show that C# developers are still amongst the highest paid developers out there.
So you shouldn't have too much trouble finding employment in the field nor will you go hungry or wanting.

![bugs money](https://media.giphy.com/media/67ThRZlYBvibtdF9JH/giphy.gif)

## Backed by Microsoft

Hate them or love them they are undoubtedly one of the largest and most successful companies in the tech world. One thing Microsoft
was always good at was making sure their development ecospace is of top quality. You can be sure that tools such as Visual Studio and Visual Studio code will
work effortlessly with your technology stack. You can also rest assured that the language and framework will be regularly updated and kept simple and concise for many years to come.

![bill gates dancing](https://media.giphy.com/media/xTiTnvMb8gkmBvwFiM/giphy.gif)

## Not just Windows anymore, it does Linux and Mac now too.

Since the release of .NET Core 1.0 Microsoft has been putting in a lot of work trying to open source as much of their stuff as possible.
With that finally came official support for Linux and OSX, which means you can now use official C# libraries on Linux or a MAC without having to
resort to using Mono. This means you can have the best of both worlds a fast and efficient Linux server with lighting fast C# running your websites, webapps or services.

speaking of which...

## It's BLAZINGLY fast

And I mean FAST, it still outperforms Java, NodeJS and most of the competition, the only languages that can boast about being more resource friendly and therefore fast would be
C, and C++. However, their speed and performance come at a price. In both of them, you have to take care of memory management and trash collection yourself. While C# has a built in trash collector that
Does a pretty damn good job of cleaning up after itself 🥁 💥.

![super fast](https://media.giphy.com/media/3oriNYQX2lC6dfW2Ji/giphy.gif)

## it comes with built in pun functionallity

Don't believe me observe:

> Why do Java developers wear glasses
>
> because they can't C#

## Native mobile application

By using Xamarin you can write **fully native** mobile applications for both Android and iPhone without having to support two different codebases.
This enables you to develop your mobile apps faster and more efficiently. The only thing you need to figure out now is how you're gonna spend all that extra time you'll have.
I heard the outdoors are supposed to be good for you.

## C# is multifunctional

With C# you can write anything from games, mobile apps with Xamarin, desktop applications, web applications, websites and webshops. There are only a few languages out there that are that multifunctional
and none of them is as clean and nice to look at as C#.
