
import Callout from "../../src/components/markdown/Callout";

Have you ever been in this situation where you are working on multiple projects and have to deal with multiple versions of Java, NodeJS or Postgres? In this article, we’ll discover how to switch between different runtime versions automatically depending on the current folder, and therefore the project. 📁

- [Setting the Scene](#setting-the-scene)
- [ASDF: Our Magic Wand](#asdf-our-magic-wand)
- [An Example](#an-example)
- [Setting Up ASDF](#setting-up-asdf)
- [Usage](#usage)
- [Wrapping Up](#wrapping-up)


## Setting the Scene

As a freelance developer working on different projects for different clients, you have probably already found yourself in this situation: project A runs with Java 8, project B runs with Java 11, and project C runs with Java 17. To easily switch between these versions, you might have used the `update-alternatives` command.

```bash
sudo update-alternatives --config java
```

This works pretty fine, but there is a drawback to this approach: you have to manually run this command every time you have to switch to another version, which can quickly get cumbersome. Also, this command does not work with all tools, such as `node` or `postgres`.

One way to solve this problem is to use Docker. Indeed, the purpose of Docker is to create an image that contains all the correct versions for the current project. However, not everyone knows Docker, and not every project has a Dockerfile to build this setup. Also, not all teams have the time to build a Dockerfile: depending on the project size, it can easily get complicated to create one quickly.

Another solution would be to have something like a magic wand that automatically switches between Java 8 in the `project-A` folder and Java 11 in the `project-B` folder, and so on.

Actually, this magic wand exists, and is called [asdf](https://asdf-vm.com/). 🪄


## ASDF: Our Magic Wand

So what really is `asdf`? It is a CLI tool that automatically switches between your runtime versions (Java, NPM, Node, Postgres, PHP, and even more) depending on your current folder. To do so, it relies on a file named `.tool-versions` (located in the folders where you need to use it) to know which version to use for each tool. This file simply contains a mapping list of each tool with the correct version to use.

```
java openjdk-17
nodejs 17.3.0
postgres 13.5
```

When your current folder does not contain a `.tool-versions`, `asdf` will just look in the parent folders to find the first one containing such a file. As a result, you need to define a default version for each tool, so that `asdf` can use this default version if no `.tool-versions` file was found in the parent folders. The default versions are stored in your home directory: `~/.tool-versions`.

Something fascinating is that you can commit this `.tool-versions` file to your git repository so that your colleagues can also have the correct versions of the different tools, as long as they are using `asdf`. 💪🏼


## An Example

Let’s say your default `node` version is 17.3.0, but one of the projects you are working on is a bit old and uses version 12.13.0. If you start a terminal and run the command to get the `node` version, it will display your current one.

```
$ node --version
v17.3.0
```

This command will produce the same output if you are in the `project-A` folder. However, if you tell `asdf` that it should use the version 12.13.0 of `node` in this project, the output will change.

```
$ asdf local nodejs 12.13.0
$ node --version
v12.13.0
```

And if you change to another directory, the `node` version will magically change back to your default one.

```
$ cd ..
$ node --version
v17.3.0
```

Totally crazy, right? 🤯 Let’s now see how to set up `asdf` <Spoiler>and it is ridiculously easy</Spoiler>.


## Setting Up ASDF

In the first place, you will need to download `asdf` (available on Linux and macOS, but unfortunately
not on Windows). To do so, just clone the git repository to your home folder.

```
git clone https://github.com/asdf-vm/asdf.git ~/.asdf
```

<Callout status="info">
  If you are using macOS, you can simply run `brew install asdf`.
</Callout>

Once done, you will need to add these two lines to your `.bashrc` (or `.zshrc`).

```
. $HOME/.asdf/asdf.sh
. $HOME/.asdf/completions/asdf.bash
```

And that’s it, you’ve successfully installed `asdf`! 🎉


## Usage

To use `asdf`, you will first need to add the plugins you need. A plugin corresponds to a tool: for instance, you will need to add the `java` plugin to switch between java versions, the `nodejs` plugin to switch between NodeJS versions, and so on. To add a plugin, simply run the following command:

```
asdf plugin add [plugin]
```

In this example, we will continue with `nodejs`, so we will install this plugin.

```
asdf plugin add nodejs
```

<Callout status="info">
  You can list all the available plugins with the `asdf plugin list all` command. As this will produce a pretty big list,
  you can filter the results with `grep`.

  ```
  asdf plugin list all | grep node
  ```
</Callout>

Now that we’ve added the `nodejs` plugin, we will need to download the versions we want to use. In our case, we want both 12.13.0 and 17.3.0 versions.

```
asdf install nodejs 12.13.0
asdf install nodejs 17.3.0
```

After installing these versions, the last step is to specify which one to use depending on the project. To do so, head over to the folder of the project that uses 12.13.0 (let’s say `project-A`) and select the correct `nodejs` version.

```
asdf local nodejs 12.13.0
```

And that’s it! The 12.13.0 version of Node will be used in the `project-A` directory and subdirectories. 🥳

If you now run `ls -al` in the project folder to list all the files, you will notice the `.tool-versions` file that contains the correct Node version. You can commit it to your version control system.

```
nodejs 12.13.0
```

<Callout status="info">
  When cloning the project containing this file, your colleagues don’t even have to manually install the listed versions:
  they can simply run `asdf install`, and the magic wand will take care of downloading all required versions.
</Callout>

Lastly, as we’ve seen earlier, we need to define a default version to use when we are in another folder which has no `.tool-versions` file in it or in its parent folders. In our case, we want the default version of Node to be 17.3.0.

```
asdf global nodejs 17.3.0
```

<Callout status="info">
  You can also specify a version for the current shell.

  ```
  asdf shell nodejs 17.3.0
  ```
</Callout>

And that’s it, we’ve successfully got rid of the pain of having to manually switch between our runtime versions, thanks to our new magic wand. 🪄


## Wrapping Up

Thanks to `asdf`, our runtime versions are now managed automatically. When you need to use a new plugin, the steps will always be the same:

1. Install the corresponding plugin: `asdf plugin add [plugin]`
2. Install all the versions you need: `asdf install [plugin] [version]`
3. Select the local version for each concerned project: `asdf local [plugin] [version]`
4. Select the default version for this plugin: `asdf global [plugin] [version]`

For more information, or if you need help on this awesome tool, don’t hesitate to head over to [asdf-vm.com](https://asdf-vm.com/). Also, feel free to star the [GitHub Repository](https://github.com/asdf-vm/asdf) of `asdf` to support the team behind this project. 😉

I hope this article was useful to you, and I’ll see you in the next ones. 🤘🏼


ASDF: Automatic Management of Multiple Versions


import Callout from "../../src/components/markdown/Callout";

Last time, we’ve seen how to implement the [useAudio](/blog/custom-react-hooks-useaudio) Hook to simplify sounds management within our React apps. Today, let’s see how to create a Hook that tracks the visibility of our components on the screen: `useInView`.

- [Motivation](#motivation)
- [Implementation](#implementation)
- [Usage](#usage)
- [Wrapping Up](#wrapping-up)


## Motivation

First, let’s have a look at a concrete example to motivate our Hook implementation. The most obvious example is the one of infinite scrolls, like your Facebook or Instagram feed. You probably know that these applications don’t load entirely all the content you see on your screen (otherwise, the DOM would contain thousands of elements, which would drastically impact the performance of the application). Instead, they load a certain amount of posts, typically a dozen, and wait for you to scroll in order to load a dozen more, until you scroll enough to load another dozen, and so on. This way, scrolling your feed feels like you are facing an infinite list.

To achieve this, they use something called [intersection observers](https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API) that wait for a given element to be above a given “threshold” (called the root margin), as shown in the figure below.

![Intersection Observers Diagram](https://i.imgur.com/XHvm8bS.png)

When more than the defined threshold (let’s say 25%) of the 4th element will be above the root margin, a callback function will be triggered in order to load more posts. This is what our custom Hook will be in charge of.

If intersection observers are still confusing for you, don’t worry: I’ve set up a small demo project that you can play with to easily understand how they work. Just head over to this [CodeSandbox demo](https://codesandbox.io/s/intersection-observers-demo-16u0eg?file=/src/App.js) to try it out.

We can now get our hands dirty and jump into the Hook implementation. 👨🏻‍💻

## Implementation

Before implementing this new Hook, let’s discuss its signature: how do we want to use it? Typically, we want it to return a boolean value to know if the target element is visible or not.

```jsx
const isIntersecting = useInView()
```

But we have a first problem: as we’ve seen in the diagram of the previous section, the root margin is not directly the bottom of the screen. Instead, it will be an offset that we can manually set (like `100px`). We can also define the root element, from which the target element will be visible or not, as well as a visibility threshold for it (`0%`, `50%`, `100%`...). In our infinite scroll example, the root element corresponds to the browser viewport, the root margin could be set to `100px`, the threshold could be `0`, and the target element would be the footer of the page. This way, when the footer will reach `100px` from the bottom of the screen, the function for loading new posts will be triggered.

On the official documentation of intersection observers, we can see that an `options` object can be specified when creating a new instance. We will use the same object in order to keep the same logic instead of creating our own one, which could be confusing to our colleagues. Thus, our Hook signature can be changed to the following:

```jsx
const options = { root: someElement, rootMargin: '100px', threshold: 0.25 }
const isIntersecting = useInView(options)
```

<Callout status="info">
  Each key of the `options` object is optional.
</Callout>

That’s way better, but we still have a last problem: where do we specify the target element to use? Actually, we don’t want to bother with the DOM native methods, such as `document.querySelector` or `document.findElementById`. Instead, we will use the React refs (references) to simplify this. The Hook will now have another parameter: the React reference of the target element.

```jsx
const target = useRef(null)
const options = { ... }
const isIntersecting = useInView(target, options)

// ...

return <p ref={target}>Loading...</p>
```

<Callout status="info">
  Note that the `options` parameter is optional, and could be omitted.
</Callout>

This looks awesome. We are now ready to dive in the actual implementation. Let’s first set up the Hook skeleton.

```jsx
const useInView = (target, options = {}) => {
  const [isIntersecting, setIsIntersecting] = useState(false);
  return isIntersecting;
}
```

Then, we are going to set up the intersection observer logic. We will create an instance of `IntersectionObserver` when the Hook is mounted. As we’ve seen previously, the constructor takes as a parameter a callback function, that will be executed when the target meets the threshold specified for the `IntersectionObserver`. This function receives as an argument the list of entries, each one being a threshold that was crossed by one of the observed elements (but in our case, we will only have one target element, so this list will only contain this single element). Hence, our callback function is as simple as that:

```jsx
const callback = (entries) => {
  setIsIntersecting(entries[0].isIntersecting); 
}
```

Great. With this callback function and the options that we receive as arguments, we can now instantiate an `IntersectionObserver`.

```jsx
const useInView = (target, options = {}) => {
  const [isIntersecting, setIsIntersecting] = useState(false);
  const [observer, setObserver] = useState(null);

  useEffect(() => {
    const callback = (entries) => {
      setIsIntersecting(entries[0].isIntersecting);
    };

    const _observer = new IntersectionObserver(callback, options);
    setObserver(_observer);
  }, []);

  return isIntersecting;
}
```

So far, nothing happens. This is because we need to actually observe the given target after creating the instance, so that the callback gets called accordingly.

```jsx
useEffect(() => {
  const callback = (entries) => {
    setIsIntersecting(entries[0].isIntersecting);
  };

  const _observer = new IntersectionObserver(callback, options);
  _observer.observe(target);
  setObserver(_observer);
}, []);
```

Awesome. However, we need to be careful: when our Hook is unmounted, we have to stop watching the target element visibility changes so that the callback is not accidentally called. To do so, we just have to return a cleanup function inside the `useEffect` Hook that will take care of disconnecting from the observer when the Hook is unmounted.

```jsx
useEffect(() => {
  const callback = (entries) => {
    setIsIntersecting(entries[0].isIntersecting);
  };

  const _observer = new IntersectionObserver(callback, options);
  _observer.observe(target);
  setObserver(_observer);

  return () => {
    observer?.disconnect();
  };
}, []);
```

<Callout status="info">
  We are using the optional chaining operator (`?.`) to prevent from errors if for some reasons the observer is still `null`.
</Callout>

That’s way better! We are getting close to our goal. We just have one last thing to deal with: we have to listen for value changes of the observer arguments. For example, if the target element or the threshold are changed, we have to update our observer accordingly. To do so, we just have to add them to the dependency array of the `useEffect` Hook, where we will disconnect from the previous observer (if it exists), and recreate a new instance with updated values.

```jsx
useEffect(() => {
  const callback = (entries) => {
    setIsIntersecting(entries[0].isIntersecting);
  };

  observer?.disconnect(); // Disconnect from the previous observer

	// target.current can be null, in which case we do nothing
  if (target.current) {
    const _observer = new IntersectionObserver(callback, options);
    _observer.observe(target);
    setObserver(_observer);
  }

  return () => {
    observer?.disconnect();
  };
}, [target.current, options.root, options.rootMargin, options.threshold]);
```

And that's it, we are now done with our Hook. Here is the final implementation.

```jsx
const useInView = (target, options = {}) => {
  const [isIntersecting, setIsIntersecting] = useState(false);
  const [observer, setObserver] = useState(null);

  useEffect(() => {
    const callback = (entries) => {
      setIsIntersecting(entries[0].isIntersecting);
    };

    observer?.disconnect();

    if (target.current) {
      const _observer = new IntersectionObserver(callback, options);
      _observer.observe(target);
      setObserver(_observer);
    }

    return () => {
      observer?.disconnect();
    };
  }, [target.current, options.root, options.rootMargin, options.threshold]);

  return isIntersecting;
}
```


## Usage

In the first part of this article, we’ve talked about Facebook to introduce intersection observers. We are going to simulate a competitor of it, *Fuzebook*. In the following snippet, we load the user’s feed. The target element for our intersection observer will be a paragraph at the bottom of the page, containing “Loading more posts...”. We could also have used another element as the target, such as a spinner or even the page footer. Either way, the target shouldn’t be visible since we’ve defined a root margin of 150px. In fact, it could be visible if the `fetch` call (`getPosts`) takes a few seconds.

In our case, the scroll is infinite: we are never going to reach the bottom of the page since our Facebook feed typically contains hundreds (if not thousands) of posts. If your scrolling section contains fewer elements (let’s say a hundred), keep in mind that you can handle the case where you have no more elements to load (in which case you would just hide the `target` element).

Below is the code of the main component of our *Fuzebook* application.

```jsx
const App = () => {
  const posts = useArray([]);
  const page = useCounter(1);
  const loadingElement = useRef(null);
  const isIntersecting = useInView(loadingElement, {
    threshold: 1,
    rootMargin: "150px"
  });

  // Load next page posts
  useEffect(() => {
    getPosts(page.value).then((newPosts) => {
      posts.concat(newPosts);
    });
  }, [page.value]);

  useEffect(() => {
    if (isIntersecting) {
      page.increment();
    }
  }, [isIntersecting]);

  return (
    <div className="App">
      <h1>Fuzebook</h1>
      <ul>
        {posts.value.map((post, i) => (
          <Card key={i} post={post} />
        ))}
      </ul>
      <p ref={loadingElement}>Loading more posts...</p>
    </div>
  );
}
```

As you can see, we’ve reused two Hooks that we’ve implemented in previous articles: [useArray](/blog/custom-react-hooks-usearray) and [useCounter](/blog/custom-react-hooks-usecounter). This simplifies our `App` component, resulting in a very clean and readable code. The `Card` component renders a basic post card, and the `getPosts` function (that returns a promise) just fetches any rest API to get some posts.


## Wrapping Up

This article closes the Custom React Hooks series, during which we’ve discovered how to extract some logic into reusable functions in order to simplify our code. This also allowed us to reuse common logic through our application, avoiding code duplication. By doing so, we were following the Single Responsibility Principle for both our components (that now only focus on their responsibility) and our Hooks. I hope you enjoyed following this series as much as I enjoyed writing it, and I’ll see you in upcoming articles. 👋

---

Source code available on [CodeSandbox](https://codesandbox.io/s/custom-react-hooks-useinview-6cev5y?file=/src/App.tsx).


Custom React Hooks: useInView


import Callout from "../../src/components/markdown/Callout";

In the last episode of the Custom React Hooks series, we’ve discovered the
[useNetworkState](/blog/custom-react-hooks-usenetworkstate) hook to
simplify the user’s network state management. Today, we’ll explore another useful custom hook:
`useAudio`. Ready? Let’s go. 😎

- [Motivation](#motivation)
- [Implementation](#implementation)
- [Usage](#usage)
- [Wrapping Up](#wrapping-up)

## Motivation

Why would you ever need such a hook? Well, I’ll give you two examples. The first one is my personal
website, [iamludal.fr](https://iamludal.fr) (I swear this is not self-promotion 🙄), built with React,
which top navigation bar contains a button to switch between light and dark theme. Actually, if you turn
up the sound a little, you might hear a switch sound. This sound comes from this custom hook. The
second example is the [Typospeed](https://typospeed.iamludal.fr) game, where
you can hear sounds when removing a word (actually, Typospeed was built with [Svelte](https://svelte.dev/),
but you get the idea). In both examples, we need to play some sounds, and we don’t want to repeat ourselves
by manually instantiating a new audio, settings its volume, its playback rate...

```jsx
const Home = () => {
  const audio = useRef(new Audio('/switch.mp3'))

  useEffect(() => {
    audio.current.playbackRate = 1.5
    audio.current.volume = 0.8
  }, [])

  return (
    <button onClick={audio.current.play}>Play Sound</button>
  )
}
```

<Callout status="info">
  We don’t want to write all this code every time we need to use audio sounds. Also, we have to use the
  `useRef` hook in this situation and keep track of its current value in order to not recreate the audio
  instance at each component re-render.
</Callout>

That being said, we now have a sufficient reason to implement our new custom hook. Let’s get our hands dirty! 👨🏻‍💻

## Implementation

As we said in the previous part, we don’t want to repeat ourselves (and this is the major goal of
custom hooks). Therefore, our function will take optional parameters for our audio instance (which
can be either static or dynamic), corresponding to additional options.

```js
const audio = useAudio('/switch.mp3', { volume: 0.8 })
```

Also, we don’t want to bother with the `current` property: we have to extract this logic inside the
new hook. This way, we will be able to interact with the audio instance directly.

```js
audio.play()
audio.pause()
```

Hence, the skeleton will look like this:

```js
const useAudio = (src) => {
  const audio = useRef(new Audio(src))

  return audio.current
}
```

This is the first and basic version of the hook. If you don’t need to have additional options, you’re
ready to go. But we will add another parameter to this hook: an options object. Each time a given property
of that object changes, we have to update our instance. This way, the options can be updated dynamically
from outside — with another hook, such as `useState`. 

The final hook implementation now looks like this:

```js
const useAudio = (src, { volume = 1, playbackRate = 1 }) => {
  const audio = useRef(new Audio(src))

  useEffect(() => {
    audio.current.volume = volume
  }, [volume])

  useEffect(() => {
    audio.current.playbackRate = playbackRate
  }, [playbackRate])

  return audio.current
}
```

<Callout status="info">
  If you need any other options, feel free to add them depending on your needs. For instance, you could
  add an array parameter for the play method in order to only play a specific part of the audio (particularly
  useful when you have one audio file with multiple sounds, which is a technique used by some games).
</Callout>

Our hook is now ready to use. 🤘

## Usage

Back to our first example, the code can now be simplified as follows:

```js
const Home = () => {
  const audio = useAudio('/switch.mp3', { volume: 0.8, playbackRate: 1.5 })

  return (
    <button onClick={audio.play}>Play Sound</button>
  )
}
```

We’ve abstracted out all the logic inside this new hook, which leads to a simpler, cleaner and more readable code.


## Wrapping Up

With this brand-new hook, we've reduced the amount of code needed in our components to play audio files. Also, we don't
have to manually change the volume or playback rate when we need to: the hook takes care of this for us, as long as
we provide it a dynamic value (generally obtained from `useState`). Also, all this logic is now available everywhere
in our application without increasing the complexity. In the next (and last) episode, we will implement my favorite hook: `useInView`.


Custom React Hooks: useAudio


import Callout from "../../src/components/markdown/Callout";

In the last episode of the Custom React Hooks series, we've implemented the [useLocalStorage](/blog/custom-react-hooks-uselocalstorage) hook to simplify local storage management. In today's episode, we will create one to simplify the observation of our users network state: `useNetworkState`.

- [Motivation](#motivation)
- [Implementation](#implementation)
- [Usage](#usage)
- [Wrapping Up](#wrapping-up)


## Motivation

Let's say you're building an application that requires to be online in order to work correctly. If the user gets disconnected, you want to display a message informing them to check their network connectivity. To do this in a React app, here's how you could proceed:

```jsx
const App = () => {
  const [isOnline, setIsOnline] = useState(window.navigator.onLine);

  useEffect(() => {
    const handleOnline = () => setIsOnline(true);
    const handleOffline = () => setIsOnline(false);

    window.addEventListener('online', handleOnline);
    window.addEventListener('offline', handleOffline);

    return () => {
      window.removeEventListener('online', handleOnline);
      window.removeEventListener('offline', handleOffline);
    };
  }, []);

  return (
    <div>
      <h1>My Awesome App</h1>
      <p>
        Lorem, ipsum dolor sit amet consectetur adipisicing elit. Culpa
        provident tenetur molestias fugiat expedita quaerat dolores dignissimos
        dicta, error amet reiciendis voluptates delectus perspiciatis dolorum
        saepe, sunt, similique vitae illo.
      </p>
      {!isOnline && (
        <div className="toast">
          You are offline. Please check your connectivity and try again.
        </div>
      )}
    </div>
  );
};
```

This works fine, but this is already a lot of code, and above all, a lot of logic just inside the `useEffect` hook. Our goal is to define a `useNetworkState` hook that will abstract this logic inside a custom hook, that is reusable over the entire app to listen for network state changes. This will also reduce the code inside our `App` component, that could quickly get longer and longer if we add some other logic (click listeners, form submission, keyboard listeners...).


## Implementation

As always, let's think about the interface of our hook (how we are going to use it). In our case, we could have something as simple as this one-liner:

```jsx
const isOnline = useNetworkState()
```

Pretty straightforward. This hook would return a single boolean value that gets updated accordingly to synchronize with the network status.

We can already dive into the hook's implementation, by only extracting the logic we've written in the `useEffect` hook of our `App` component. At the end, the hook will look like this:

```jsx
const useNetworkState = () => {
  const [isOnline, setIsOnline] = useBoolean(window.navigator.onLine);

  useEffect(() => {
    window.addEventListener('online', setIsOnline.on);
    window.addEventListener('offline', setIsOnline.off);

    return () => {
      window.removeEventListener('online', setIsOnline.on);
      window.removeEventListener('offline', setIsOnline.off);
    };
  }, []);

  return isOnline;
};
```

Wait, what the heck is `useBoolean`? This hook doesn't exist... 🤨

Yes, you're right. However, if you've been following this series from the very first episode, this hook might remind you something, as it is the first custom hook we've implemented! If you've discovered this series on the way, no problem: just head over to [this article](/blog/custom-react-hooks-useboolean) to learn about this `useBoolean` hook.

<Callout status="info">
  If you don't want to use the `useBoolean` hook, you are free to use the native `useState` one.
</Callout>

```jsx
const useNetworkState = () => {
  const [isOnline, setIsOnline] = useState(window.navigator.onLine);

  useEffect(() => {
    const handleOnline = () => setIsOnline(true);
    const handleOffline = () => setIsOnline(false);

    window.addEventListener('online', handleOnline);
    window.addEventListener('offline', handleOffline);

    return () => {
      window.removeEventListener('online', handleOnline);
      window.removeEventListener('offline', handleOffline);
    };
  }, []);

  return isOnline;
};
```

## Usage

Back to our `App` component, where we can drastically simplify the code (see by yourself):

```jsx
const App = () => {
  const isOnline = useNetworkState()

  return (
    <div>
      <h1>My Awesome App</h1>
      <p>
        Lorem, ipsum dolor sit amet consectetur adipisicing elit. Culpa
        provident tenetur molestias fugiat expedita quaerat dolores dignissimos
        dicta, error amet reiciendis voluptates delectus perspiciatis dolorum
        saepe, sunt, similique vitae illo.
      </p>
      {!isOnline && (
        <div className="toast">
          You are offline. Please check your connectivity and try again.
        </div>
      )}
    </div>
  );
};
```

Yes, yes. One-line. Awesome, right? 😎


## Wrapping Up

We have abstracted all the network logic outside the component, which now only focuses on what matters to it. By doing this, we're following the SOC (Separation of Concerns) design principle — more information [here](https://en.wikipedia.org/wiki/Separation_of_concerns). I hope this hook will be useful to you for your projects. In the next article, we are going
to implement a hook for dealing with audios and sound effects: `useAudio`.

---

Source code available on [CodeSandbox](https://codesandbox.io/s/custom-react-hooks-usenetworkstate-354j0?file=/src/App.tsx).


Custom React Hooks: useNetworkState


import Callout from "../../src/components/markdown/Callout";

In the last episode of the Custom React Hooks series, we've implemented the [useArray](/blog/custom-react-hooks-usearray) hook to simplify arrays management. In today's episode, we'll create a hook to deal with the local storage more easily: `useLocalStorage`.

- [Motivation](#motivation)
- [Implementation](#implementation)
- [Usage](#usage)
- [Improvement Ideas](#improvement-ideas)
- [Wrapping Up](#wrapping-up)


## Motivation

In the first place, let's see why would you need to implement this hook. Imagine that you're building an application that uses some config for each user (theme, language, or settings). To save the config, you'll use an object that could look like this:

```jsx
const config = {
  theme: 'dark',
  lang: 'fr',
  settings: {
    pushNotifications: true
  }
}
```

In the settings page, you would let the user customize its configuration, in which case you will need to synchronize the UI state with the local storage. For instance, the settings page could look like this:

![Settings page preview](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bpr40cqmb5p2ksk69ll8.png) 

And the corresponding source code could be similar to this:

```jsx
const defaultConfig = {
  theme: 'dark',
  lang: 'fr',
  settings: {
    pushNotifications: true
  }
};

const Settings = () => {
  const [config, setConfig] = useState(() => {
    const saved = localStorage.getItem('config');
    if (saved !== null) {
      return JSON.parse(saved);
    }
    return defaultConfig;
  });

  const handleChange = (e) => {
    setConfig(oldConfig => {
      const newConfig = {
        ...oldConfig,
        settings: {
          ...oldConfig.settings,
          pushNotifications: e.target.checked
        }
      };

      localStorage.setItem('config', JSON.stringify(newConfig));
      return newConfig;
    })
  }

  return (
    <>
      <h1>Settings</h1>
      <label htmlFor="pushNotifications">
        Push Notifications
      </label>
      <input
        type="checkbox"
        id="pushNotifications"
        checked={config.settings.pushNotifications}
        onChange={handleChange}
      />
    </>
  );
};
```

As you can see, that's already a lot of code for just toggling a push notifications setting. Also, we have to manually synchronize the state of the configuration with the local storage, which is very cumbersome. If we don't pay enough attention, this could lead to some desynchronization.

With our `useLocalStorage` hook, we will be able to abstract some generic logic in a separate function to reduce the amount of code needed for such a simple feature. Also, we won't have to synchronize anything anymore: this will become the hook's responsibility.


## Implementation

In the first place, let's discuss the hook's signature (what are its parameters and its return value). The local storage works by associating some string values to some keys.

```jsx
// Get the value associated with the 'config' key
const rawConfig = localStorage.getItem('config');

// Parse the plain object corresponding to the string
const config = JSON.parse(rawConfig);

// Save the config
localStorage.setItem('config', JSON.stringify(config));
```

As a result, our hook signature could look like this:

```jsx
const [config, setConfig] = useLocalStorage('config');
```

The hook will set our `config` variable to whatever value it finds in the local storage for the `'config'` key. But what if it doesn't find anything? In that case, the `config` variable would simply be set to `null`. 

We could be able to set a default value (in our example, set a default config) for this variable in case the local storage is empty for that key. To do so, we'll slightly change the hook's signature to accept the default value as an optional argument.

```jsx
const [config, setConfig] = useLocalStorage('config', defaultConfig);
```

We're now ready to start implementing the hook. 😎

First, we will read the local storage value corresponding to our `key` parameter. If it doesn't exist, we will return the default value.

```jsx
const useLocalStorage = (key, defaultValue = null) => {
  const [value, setValue] = useState(() => {
    const saved = localStorage.getItem(key);
    if (saved !== null) {
      return JSON.parse(saved);
    }
    return defaultValue;
  });
};
```

We have made the first step of the implementation. But what happens if the `JSON.parse` method throws an error? We didn't handle this case yet. Let's fix that by returning the default value once more.

```jsx
const useLocalStorage = (key, defaultValue = null) => {
  const [value, setValue] = useState(() => {
      const saved = localStorage.getItem(key);
      if (saved !== null) {
        try {
          return JSON.parse(saved);
        } catch {
          return defaultValue;
        }
      }
      return defaultValue;
  });
};
```

That's better. Now, what's next? Well, we just need to listen for the `value` changes and update the local storage accordingly. To do so, we will use the `useEffect` hook.

```jsx
const useLocalStorage = (key, defaultValue = null) => {
  const [value, setValue] = useState(/* ... */);

  useEffect(() => {
    const rawValue = JSON.stringify(value);
    localStorage.setItem(key, rawValue);
  }, [value]);
};
```

<Callout status="warning">
  Be aware that the `JSON.stringify` method can also throw errors. What should you do then? Propagate it? This is up to you.
</Callout>

So, are we done? Not yet. First, we didn't return anything. Accordingly, to the hook's signature, we just have to return the value and its setter.

```jsx
const useLocalStorage = (key, defaultValue = null) => {
  const [value, setValue] = useState(/* ... */);

  useEffect(/* ... */);

  return [value, setValue];
};
```

But we also to have to listen for the `key` changes! Indeed, the value provided as an argument in our example was a constant (`'config'`), but this might not always be the case: it could be a value resulting from a `useState` call. Let's also fix that.

```jsx
const useLocalStorage = (key, defaultValue = null) => {
  const [value, setValue] = useState(/* ... */);
  const [oldKey, setOldKey] = useState(key)

  useEffect(() => {
    const rawValue = JSON.stringify(value);
    localStorage.setItem(key, rawValue);
    localStorage.removeItem(oldKey);
    setOldKey(key);
  }, [key, value]);

  return [value, setValue];
};
```

<Callout status="info">
  As you can see, we also take care of removing the previous key (and value) from the local storage
  in order to not overload the storage.
</Callout>

With this implementation, we are now done. However, you can still customize this hook depending on your needs. For instance, if you need to deal with the session storage instead, just change the `localStorage` calls to `sessionStorage` ones. We could also imagine other scenarios, like adding a `clear` function to clear the local storage value associated with the given key. In short, the possibilities are endless, and I give you some enhancement ideas in a following section.


## Usage

Back to our settings page example. We can now simplify the code that we had by using our brand-new hook. We don't have to synchronize anything anymore. Here's how the code will now look like:

```jsx
const defaultConfig = {
  theme: "light",
  lang: "fr",
  settings: {
    pushNotifications: true
  }
};

const Settings = () => {
  const [config, setConfig] = useLocalStorage("config", defaultConfig);

  const handleChange = (e) => {
    // Still a bit tricky, but we don't really have any other choice
    setConfig(oldConfig => ({
      ...oldConfig,
      settings: {
        ...oldConfig.settings,
        pushNotifications: e.target.checked
      }
    }));
  };

  return (
    <>
      <h1>Settings</h1>

      <label htmlFor="pushNotifications">Push Notifications</label>
      <input
        type="checkbox"
        id="pushNotifications"
        checked={config.settings.pushNotifications}
        onChange={handleChange}
      />
    </>
  );
};
```

## Improvement Ideas

- Handle errors of the `JSON.stringify` method if you need to
- If the value becomes `null`, clear the local storage key (with `localStorage.removeItem`)
- Create a generic `useStorage` hook that takes the storage object to use as an argument.


## Wrapping Up

Once more, we've drastically simplified our code by implementing a custom hook. However, our implementation
is not limited to what we currently have: we could enhance it and customize it the way we want depending on
our needs, which is why these hooks are so powerful. In the next episode, we will have a look at another
useful one: `useNetworkState`.

---

Source code available on [CodeSandbox](https://codesandbox.io/s/red-grass-0pdve?file=/src/App.tsx).


Custom React Hooks: useLocalStorage


Another week, another custom React hook for your hooks backpack. In this episode, we'll implement the `useArray` hook to make arrays management easier. Ready? Let's go! 😎

- [Motivation](#motivation)
- [Implementation](#implementation)
- [Usage](#usage)
- [Improvement Ideas](#improvement-ideas)
- [Wrapping Up](#wrapping-up)


## Motivation

As usual, let's first discover how this hook could be useful to you. Let's be original and creative: suppose you are building a To-Do list application with React. At some point, you'll have to manage the user's tasks: to do so, you'll use an array, along with the `useState` hook. The `addTask` function might look like this:

```jsx
const addTask = (newTask) => {
  setTasks(oldTasks => [...oldTasks, newTasks])
}
```

Then, you would have a `removeTask` function, that could look like this:

```jsx
const removeTask = (index) => {
  setTasks(oldTasks => oldTasks.filter((_, i) => i !== index))
}
```

As you can see, this can quickly become a bit hard to read. This is why we will create the `useArray` hook to simplify our code.


## Implementation

First, let's create the hook's base structure.

```jsx
const useArray = (initialValue = []) => {
  const [value, setValue] = useState(initialValue)

  return { value, setValue }
}
```

We will then add the `push` function to add an element at the end of the array.

```jsx
const push = element => {
  setValue(oldValue => [...oldValue, element]);
};
```

Let's also create the `remove` function to remove an element at a given index.

```jsx
const remove = index => {
  setValue(oldValue => oldValue.filter((_, i) => i !== index));
};
```

It can also be handy to add an `isEmpty` function to check for the array emptiness.

```jsx
  const isEmpty = () => value.length === 0;
```

Combining all these functions together, here's how the final hook will look like:

```jsx
const useArray = (initialValue = []) => {
  const [value, setValue] = useState(initialValue);

  const push = element => {
    setValue(oldValue => [...oldValue, element]);
  };

  const remove = index => {
    setValue(oldValue => oldValue.filter((_, i) => i !== index));
  };

  const isEmpty = () => value.length === 0;

  return { value, setValue, push, remove, isEmpty };
};
```

If you are working with large amount of data, feel free to optimize this hook by using `useCallback` (more info [here](https://dmitripavlutin.com/dont-overuse-react-usecallback/)).

> Example:
> ```jsx
> const push = useCallback(element => {
>   setValue(oldValue => [...oldValue, element])
> }, [])
> ```

Also, if you need other array methods such as `map` or `unshift`, don't  hesitate to adapt it to your needs (you can even add custom functions).


## Usage

Back to our To-Do list example. By using our brand-new hook, this is how the component could now look like:

```jsx
const TodoList = () => {
  const tasks = useArray([]);
  const [newTask, setNewTask] = useState("");

  // "Add" button clicked
  const handleSubmit = e => {
    e.preventDefault();
    tasks.push(newTask);
    setNewTask("");
  };

  const handleInputChange = e => setNewTask(e.target.value);

  return (
    <>
      <h1>Todo List</h1>
      <form onSubmit={handleSubmit}>
        <input type="text" value={newTask} onChange={handleInputChange} />
        <button>Add</button>
      </form>
      {tasks.isEmpty() ? (
        <p>No tasks to display</p>
      ) : (
        <ul>
          {tasks.value.map((task, index) => (
            <li key={index}>
              <input
                type="checkbox"
                onClick={() => tasks.remove(index)}
                checked={false}
              />
              {task}
            </li>
          ))}
        </ul>
      )}
    </>
  );
};
```

Notice that we don't even need the `addTask` and `removeTask` functions anymore, as our `tasks.push` and `tasks.remove` ones are already explicit and easy to read.


## Improvement Ideas

To go further, here are some ideas for improvement to enhance this hook.

- Adding a `reverse` function to reverse the array
- Adding a `sort` function to sort the array
- Adding a `clear` function to clear the array


## Wrapping Up

Once again, we've seen how powerful custom React hooks can be: our code is much simpler, cleaner, and all the redundant logic is moved away in a separate function. I hope this hook will be useful to you for your future (or existing) projects, and see you next time for a new custom hook. 😎

---

Source code available on [CodeSandbox](https://codesandbox.io/s/custom-react-hooks-usearray-fi13z?file=/src/App.js).


Custom React Hooks: useArray


import Callout from "../../src/components/markdown/Callout";

You may already know how to add a README to your GitHub profile (if you don't, have a look at [this article](/blog/customize-github-profile)), but did you know that you can also add one to an organization's profile? 🤔

To do so, just head over to the GitHub organization you want to customize, and create a new repository named `.github`.

![GitHub special repository](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nruc4qll5iyaytrlmm0k.png)

As you can see, GitHub already tells you that you discovered a special repository (once again 😛).

<Callout status="warning">
  Make sure to set the repository's visibility to __**public**__.
</Callout>

From there, all you have to do is creating a `profile/README.md` file within this repository.

![Editing the README.md file](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ivnsybnfd8zts2hk9bsz.png) 

We can then see the final result on the organization's GitHub homepage:

![Final Result](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/amfrvl9oyomdrhv26ap8.png) 

---

## References

- [Customizing your organization's profile - GitHub Docs][link]

[link]: https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/customizing-your-organizations-profile



How to Add a README to a GitHub Organization's Profile?


import Callout from "../../src/components/markdown/Callout";

In the last episode of the Custom React Hooks series, we have implemented the [useBoolean](/blog/custom-react-hooks-useboolean) hook. Today, we will create a not more complicated one: `useCounter`. As its name suggests, this hook will help us manage the state of a counter thanks to utility methods. Ready? Let's jump right into it. 🚀


## Motivation

As always, let's see why would you want to implement this hook. Imagine you are building an e-commerce website. Whenever a customer wants to buy an item, he should be able to select the quantity. This is how the user interface might look like (let's forget about the style):

![UI](https://cdn.hashnode.com/res/hashnode/image/upload/v1633869919339/RLNAmwg8y.png)

And the source code of the `Cart` component might look like this:

```jsx
const Cart = () => {
  const [quantity, setQuantity] = useState(0);

  return (
    <div className="Cart">
      <h1>My Cart</h1>
      <Item
        label="My awesome item"
        quantity={quantity}
        onIncrement={() => setQuantity((q) => q + 1)}
        onDecrement={() => setQuantity((q) => q - 1)}
        onReset={() => setQuantity(0)}
      />
    </div>
  );
}
```

<Callout status="info">
  Of course, this example is extremely simplified in order to only focus on what matters the most in this article.
</Callout>

The above component could be simplified by getting rid of those awful arrow functions. Moreover, as we are probably going to use such a counter logic in other parts of our app, we should extract it in a separate hook to avoid code duplication. That's why we will implement a custom `useCounter` hook. Let's now get our hands dirty. 😎

## Implementation

Our hook will have a state to hold the counter value. It will also have 3 methods to update it: `increment`, `decrement`, and `reset`. With this in mind, we can create the hook in the following way:

```jsx
const useCounter = (initialValue) => {
  const [value, setValue] = useState(initialValue);

  const increment = () => setValue(c => c + 1);
  const decrement = () => setValue(c => c - 1);
  const reset = () => setValue(initialValue);

  return { value, increment, decrement, reset };
};
```

Now, some of you might wonder why the 3 exported methods are not wrapped into the `useCallback` hook, which prevents from recreating them every time the component is re-rendered (more info [here](https://dmitripavlutin.com/dont-overuse-react-usecallback/#2-the-purpose-of-usecallback)). In our case, the component is so simple that calling `useCallback` 3 times to improve performance could have the opposite effect. This hook should be used when you know your function will be used in a more complex component, for instance one that holds a big list of items, each one using your function as an event handler (such as `onClick`).

<Callout status="info">
  For more information, don't hesitate to have a look at [this article](https://dmitripavlutin.com/dont-overuse-react-usecallback) from [Dmitri Pavlutin](https://dmitripavlutin.com/), which goes into details about why, when and how to use the `useCallback` hook. The same applies for `useMemo` and `useRef` (except when used as a reference to an element).
</Callout>

That being said, our new custom hook is now ready to use! 🥳


## Usage 

Let's get back to our e-commerce website example. Given that we just created this brand new custom hook,
the `Cart` component can now be simplified as follows:

```jsx
function Cart() {
  const quantity = useCounter(0);

  return (
    <div className="Cart">
      <h1>My Cart</h1>
      <Item
        label="My awesome item"
        quantity={quantity.value}
        onIncrement={quantity.increment}
        onDecrement={quantity.decrement}
        onReset={quantity.reset}
      />
    </div>
  );
}
```

We've got rid of all the arrow functions, which resulted in a cleaner and more readable code.


## Improvement ideas

If you want to go further, here are some ideas for improvement to enhance the `useCounter` hook. Don't hesitate to try implementing one or more of these ideas, so that you can practice on your own.

- Adding an increment (and decrement) step: `counter.increment(step)`
- Adding a min (and max) value: `useCounter({ min: 0, max: 10, initial: 0})`
- Manually set the counter value: `counter.set(value)`


## Wrapping Up

With this new custom hook, we now have a new string to our bow. So far, the hooks we are creating are pretty simple, and can even be considered superfluous by some. In the next articles, we will start implementing more complex hooks to really help us simplify our components code and avoid code duplication.

---

Source code available on [CodeSandbox](https://codesandbox.io/s/custom-react-hooks-usecounter-5w9gk?file=/src/hooks/useCounter.ts)


Custom React Hooks: useCounter


import Callout from "../../src/components/markdown/Callout";

React hooks initially allow you to "hook into" React state and lifecycle features, like we used to do with the `componentDidMount` or `componentWillUnmount` methods when using class based components. What we'll discover in this series of articles is that we can implement our own custom hooks, using the few primitives hooks that React provides us (like `useState` and `useEffect`). This way, we can drastically reduce the cognitive complexity of our components, by moving away some logic into functions that we will be able to reuse anywhere in our React applications. The code will look cleaner, and we will be following the Single Responsibility Principle (SRP), which states that each class or function (or, in our case, component) should have responsibility over a single part of a program's functionality, and it should encapsulate that part.

Enough talk, let's get to work and implement our first custom hook: `useBoolean`. 😎


## Motivation

First, why are we going to implement such a hook? Let's have a look at this simple component:

```jsx
const Spoil = ({ content }) => {
  const [spoilVisible, setSpoilVisible] = useState(false);

  return (
    <div className="spoil">
      <button onClick={() => setSpoilVisible(visible => !visible)}>
        {spoilVisible ? "Hide" : "Show"}
      </button>
      {spoilVisible && <div className="spoil-content">{content}</div>}
    </div>
  );
};
```

The component receives a `content` prop, that only appears once the button gets clicked to show the spoil. Clicking the button again will hide it back, and so on.

Here, the component is so simple that it is already easy to read, but we could improve its readability by extracting the button `onClick` listener to a separate function:

```jsx
const Spoil = ({ content }) => {
  const [showSpoil, setShowSpoil] = useState(false);

  const toggle = () => setShowSpoil((visible) => !visible)

  return (
    <div className="spoil">
      <button onClick={toggle}>
        {showSpoil ? "Hide" : "Show"}
      </button>
      {showSpoil && <div className="spoil-content">{content}</div>}
    </div>
  );
};
```

That's better. We've simplified the return value of our function, but we've added a new line between the state initialization and the return statement. Of course this is not a major problem in our case, but when dealing with more complex components, this can lead to redundant functions declarations.

In fact, our component could be further simplified if we had a `useBoolean` hook, that we would use like this:

```jsx
const Spoil = ({ content }) => {
  const [showSpoil, setShowSpoil] = useBoolean(false);

  return (
    <div className="spoil">
      <button onClick={setShowSpoil.toggle}>
        {showSpoil ? "Hide" : "Show"}
      </button>
      {showSpoil && <div className="spoil-content">{content}</div>}
    </div>
  );
};
```

See? We didn't add any extra function, and the `onClick` listener is easier to read. Now, let's move into the implement of this simple hook, shall we? 😎


## Implementation

First, we define a function in which we can use the `useState` hook.

```jsx
const useBoolean = (initialValue) => {
	const [value, setValue] = useState(initialValue)

	return [value, setValue]
}
```

<Callout status="warning">
  Be careful: we will only be able to use the `useBoolean` function (or should I say hook) in React components, as it uses the `useState` one.
</Callout>

So far, we've just created an alias for the `useState` hook. Not very useful...😅

The interesting part comes now: we will replace the `setValue` function in the return array by an object that will contain 3 methods:

- `toggle()` to toggle the value
- `on()` to set the value  to `true`
- `off()` to set the value to `false`

Our hook now looks like this:

```jsx
const useBoolean = (initialValue) => {
	const [value, setValue] = useState(initialValue)

	const updateValue = useRef({
		toggle: () => setValue(oldValue => !oldValue),
		on: () => setValue(true),
		off: () => setValue(false)
	})

	return [value, updateValue.current]
}
```

<Callout status="info">
  We've wrapped the object in the `useRef` hook to prevent React from re-creating it at each re-render.
</Callout>

And here it is, you've just created your first custom hook, congratulations! 🥳


## Usage

```jsx
const Articles = () => {
  const [articles, setArticles] = useState([])
	const [isLoading, setIsLoading] = useBoolean(false)
	const [isError, setIsError] = useBoolean(false)

	useEffect(() => {
		setIsLoading.on()
		fetch(someApiEndpoint)
			.then(res => res.json())
			.then(setArticles)
			.catch(setIsError.on)
			.finally(setIsLoading.off)
  }, [])

	return // ...
}
```

<Callout status="warning">
  You can't use `setIsLoading(true)` as we don't export a function anymore but an object.
</Callout>

See how the above snippet is very easy to read? 😎


## Wrapping Up

We've discovered how we can abstract some logic outside our components to make them lighter and easier to read. And that's 
the main idea behind custom React hooks. In the next article, we will implement another useful one: `useCounter`.

---

## References

- [https://reactjs.org/docs/hooks-overview.html](https://reactjs.org/docs/hooks-overview.html)
- [https://en.wikipedia.org/wiki/Single-responsibility_principle](https://en.wikipedia.org/wiki/Single-responsibility_principle)


Custom React Hooks: useBoolean


import Callout from "../../src/components/markdown/Callout";

At some point in your JavaScript developer journey, you've certainly encountered these awful relative imports: 

```js
import Car from '../../../vehicles/car'
import House from '../../../buildings/house'
```

And you were probably bothered by the ugliness of them.

![Disgusting GIF](https://media.giphy.com/media/3o8doVY3jacRLyrSmI/giphy.gif)

But guess what? I'm here as a savior to show you how to get rid of them.


## baseUrl

The simplest way to get rid of these awful imports is by simply editing your `jsconfig.json` file. If you don't already have one, you can just create it at the root of your project.

You can then complete it with the following keys:

```json
{
	"compilerOptions": {
		"baseUrl": "."
	}
}
```

The most studious ones of you might think:

<Callout status="question">
  Compiler options? But JavaScript is not a compiled language. 🤨
</Callout>

And you're totally right. If you want to know why does this key exist, I recommend you to follow [this link](https://code.visualstudio.com/docs/languages/jsconfig#_what-is-jsconfigjson) from the official website of Visual Studio Code.

Now, imagine having the following directory structure:

```
.
├── components
│   └── layouts
│       └── header.js
├── styles
│   └── header.css
└── jsconfig.json
```

If you want to include your `header.css` style file in your `header.js` file, you can now do it this way:

```js
import 'styles/header.css'
```

<Callout status="info">
  Without this configuration, here is how you would have done it:

  ```js
  import '../../styles/header.css'
  ```
</Callout>

From now, no matter how deep you are in your project's architecture, you'll be able to import your files as if you were at the root of your project. 🤯

And obviously, you'll still be able to import them relatively from the current directory you are in.

```
.
├── src
│   ├── vehicles
│   │   └── car.js
│   │   └── truck.js
│   └── index.js
└── jsconfig.json
```

```js
// index.js
import truck from './vehicles/truck.js'
```

![Shocked GIF](https://media.giphy.com/media/oYtVHSxngR3lC/giphy.gif)

However, it might not be a good idea to stop there: how would you differentiate your project imports
from your dependencies?

## Paths

In our `jsconfig.json` file, we can also add the `paths` key in order to map an import to a specific folder. This is useful for giving aliases to some folders in your imports.

```json
{
	"compilerOptions": {
		"baseUrl": ".",
		"paths": {
			"css/*": ["styles/*"]
		}
	}
}
```

Considering the same folder structure we've seen in the previous part, you could now import your styles like this:

```jsx
// header.js
import 'css/header.css'
```

<Callout status="warning">
  I wouldn't recommend doing this at all, as this would create inconsistencies between the real folders names and the aliases. Instead, you could simply rename the actual folder.
</Callout>

Nevertheless, this option can be useful to differentiate your project imports and your dependencies. Let's consider
the following folder structure.

```
.
|── src
|   ├── styles
│   │   └── index.css
│   └── index.js
└── jsconfig.json
```

A common path mapping convention is to use the `@` prefix for your project imports.

```json
{
	"compilerOptions": {
		"baseUrl": ".",
		"paths": {
			"@/*": ["src/*"]
		}
	}
}
```

After that, here's how you would import your styles:

```jsx
import '@/styles/index.css'
```

Also, if you have another folder outside the `src` one, you could add another mapping.

```
.
|── assets
|   └── styles
│       └── index.css
|── src
│   └── index.js
└── jsconfig.json
```

```json
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["src/*"],
      "@assets/*": ["assets/*"]
    }
  }
}
```


## TypeScript

Oh, you are using TypeScript? Awesome. Of course, you can also use this trick: the only difference is that you won't write those settings inside the `jsconfig.json` file, but instead, inside...?

![Smart GIF](https://media.giphy.com/media/3o7TKTDn976rzVgky4/giphy.gif)

Exactly: inside the `tsconfig.json` file. Smart, isn't it?


## Wrapping Up

Congratulations! You've now got rid of those awful imports. 🎉

To go further, I would recommend you following [this link](https://code.visualstudio.com/docs/languages/jsconfig) from the official Visual Studio Code website to learn more about the `jsconfig` file.

With that being said, thank you for reading me all the way through, and I hope you've learned something with this article. 😎

![Thank you GIF](https://media.giphy.com/media/3o6Zt6KHxJTbXCnSvu/giphy.gif)


Tired Of Relative Imports? Time To Get Rid Of Them!


import Callout from "../../src/components/markdown/Callout";


After going through many GitHub profiles, I noticed that **most of them are not really appealing**. In this article, I will give you some pro-tips to enhance yours.

As of September 2020, [GitHub](https://github.com) reports having more than **58 million users**. In order to stand out from the crowd, your profile should be unique and reflect your own identity.

Here are the reasons why your GitHub profile might be boring.


## Reason #1: You Don't Have A Profile Picture

Yes, we're starting with the simplest and the most obvious one, but you **must** have a profile picture. It can be either a picture or you, an avatar that looks like you, or even just a logo or a background, but it needs to **reflect your identity** in some way. People should be able to recognize your profile just by looking at your profile picture.

Here's one of the GitHub default profile pictures:
![GitHub default profile picture](https://cdn-images-1.medium.com/max/1000/1*P0hlfc1JnHRRSdayQcAIhg.png)

> 🤮 Not appealing at all...

As you might have seen, my profile picture is a [memoji](https://www.pocket-lint.com/phones/news/apple/144743-what-are-memoji-how-to-create-an-animoji-that-looks-like-you) that looks like me. This means that it is (almost) unique, and **it reflects my own identity**.

![My profile picture](https://i.imgur.com/q4Rdj5I.png)

I really encourage you finding a profile picture that will make your profile unique too.


## Reason #2: Your Profile Is Incomplete

GitHub, such as many other famous social networks, allows you to fill in some information about you. This **doesn't mean** that you have to share your phone number or your address, but again, you need to have an identity.

What can you put on your profile?

- A short biography
- Your work place
- Where you are from
- A link to any website
- Your Twitter username

<Callout status="info">
  The more information you fill in, the better.
</Callout>

Now, if you think that some of these points are personal, I totally agree with you, and you don’t necessarily have to fill them all.

Nevertheless, when people are browsing your profile, they must be able to know the main stuff about you. Your profile has to draw out what you are interested in, some of your recent projects, possibly a link to your personal website —  or if you don’t have one, to your LinkedIn profile.

<Callout status="info">
  Also, don’t hesitate to include emojis in your biography. This way, your presentation will grab the users’ attention by creating some anchor points. But beware not to overuse them though.
</Callout>

We can consider my case, but also some of other presentations that caught my attention.

![Some profile biographies](https://miro.medium.com/max/875/1*KS4cxsqIQnuzG3e78l2rOQ.png)

Your profile is getting on fire, **congratulations**! 🎉


## Reason #3: You Don’t Have A Profile Presentation

<Callout status="question">
  Uh? Ludal, we just added a profile presentation in the previous part, what are you saying?
</Callout>

Yes, you're right. However, you might have noticed that the maximal length for your biography is actually quite short: 160 characters.

This is why in July 2020, GitHub secretly released a new feature: **profile README**.

It allows you to add a fully detailed presentation to your profile page, using the [Markdown](https://en.wikipedia.org/wiki/Markdown) syntax. This is the perfect place to detail whatever technologies you use, what you are currently working on, additional contact information, etc.

Here's an example of what it can look like:

![A profile README example](https://miro.medium.com/max/875/1*iCDuKOlaKuvLxgf2Z37mxA.png)

This tip really gives your profile an incredible **boost**, making it even more different and personal.

<Callout status="question">
  Now, how do you add this to your profile?
</Callout>

In fact, the steps are ridiculously easy: just head over to [GitHub](https://github.com), and create a new repository with the same name as your username.

![Special repository](https://miro.medium.com/max/875/1*0qBY5IJRvOorJq1QOmcjgA.png)

As you can see, this small paragraph comes in, saying that you just discovered a **special repository**. *Yee-haw!*

Now, you just need to add a file named `README.md` at the root of this repository and add whatever you want people to know about you — obviously, using the Markdown syntax.

Here are a few (subjective) tips for an awesome profile presentation:

1. **Add emojis**, but don't overuse them.
2. **Structure it**, with some titles, and why not subtitles.
3. **Add GIFs or images** — don't abuse them either.
4. **Add special elements**, such as you [profile stats](https://github.com/anuraghazra/github-readme-stats) or [icons](https://devicon.dev/).
5. **Stay consistent** — for instance, if you decide to include an emoji before a title, do it for *every* title, or do not.

But what if you're not inspired? Well, there are some great repositories such as [this one](https://github.com/elangosundar/awesome-README-templates) or [this one](https://github.com/kautukkundan/Awesome-Profile-README-templates), which contains some templates made by other people, that you can freely download and reuse. Then you just have to change their content to make them yours.

<Callout status="info">
  Don't hesitate to browse several templates and take the parts you like in either of them. Then, simply merge those parts together in order to get your own and unique presentation!
</Callout>

Also, if you're not familiar at all with the Markdown syntax, you can either use [this cheatsheet](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) for a full reference, or even use websites such as [Profilinator](https://profilinator.rishav.dev/) that allow you to generate some dope presentations without having to write a single line of Markdown.

![Screenshot of Profilinator](https://miro.medium.com/max/875/1*VoTOuZc4iyf3n4valfEV8w.png)


## Reason #4: You're Not Interacting With Others

GitHub on its own is kind of a social network, as it allows you to follow people, star other ones' projects, etc.

This is why you **must** show everyone that you actually exist!

![Sheldon running](https://media.giphy.com/media/ieebdd3BJxd3aqPc5p/giphy.gif)

To do so, you only need to follow users and star projects. As simple as that.

Indeed, star projects you’re interested in. **Don’t star thousands of projects just to star them.** The same applies for people you will follow.

And as you now have an awesome profile, with (I’m pretty sure) wonderful projects on it, they might follow you back and/or star one (or more) of your projects.


## Reason #5: You Don’t Have Any Pinned Projects

Last but not least, here’s another small trick.

You can actually pin **up to 6 projects**, which will be displayed directly on your profile’s public page.

How to do so? Again, it's trivial. Just head over to your profile’s public page (which is `github.com/your-username`) and search for the *“Pinned”* section. From here, just click the *“Customize your pins”* button on the right side, and select your most relevant projects.

I would personally recommend using an even number of projects to pin, so that they are displayed symmetrically, which is nicer than having a trailing blank.

Here’s the result:

![Pinned repositories](https://miro.medium.com/max/875/1*Z_JKOmoAMRP9cKCckudKdQ.png)


## Wrapping Up

Now that you have applied all the steps above, here’s how the final result might look like:

![Final result](/images/articles/github-profile-iamludal.webp)

Thanks (and congratulations) for reading me all the way through. You now have a fully customized GitHub profile that really stands out from the crowd, and most importantly, that reflects your own identity. 🎉



Why Your GitHub Profile Sucks


import Image from '../../src/components/markdown/Image'

As a web, mobile or software developer, you’re probably including *emojis* in your application **the wrong way**. This is why.


## Starting With An Example

The common way for programmers to include emojis in their application is to simply **copy** them, for instance from a website such as [Emojipedia](https://emojipedia.org) or a built-in application, and then **paste** it into the source code. 

- Source code:
```html
<h2>
  I'm a pretty header! 🎉
</h2>
```

- Output:

![Heading with emoji](https://i.imgur.com/7uHuYJK.png)


## The Problem

As you can see, including emojis that way seems to work just fine. The emoji we copy-pasted is rendered the way we wanted, **yee-haw!**

Now, imagine being **so proud** of the application or feature you just created that you want to showcase it, let's say, to your grandparents.

![Grandparents](https://miro.medium.com/max/625/0*h37eAJKCXfdj5Wut.gif)

As you might have guessed, your grandparents may not have the latest smartphone or laptop on the market. It might **not display emojis at all**, or just the emoji you used is **not supported yet** by their device.

Hence, this is what they could see:

![Heading with broken emoji](https://i.imgur.com/I4PCzM6.png)

Probably not what you wanted them to see...

## Why Does This Happen?

From [phonearena](https://www.phonearena.com/news/How-do-Emoji-work-a-guide-to-Emoji-history-nature-and-usage_id88761):

> *Emoji works exactly the same way as regular text — a Unicode code point corresponds to every character in the Unicode catalog, Emoji included. When a device sends a message, it sends a series of Unicode code points. When another device receives said message, it interprets the code points and displays letters, numbers and Emojis. It’s actually a bit more complicated than that, but this is the basic principle.*

As you can see, the emoji is interpreted **by the device**, which means that their appearance may **vary from one device to another**.

Thus, it may not appear the way you wanted the user to see it, and possibly alter your application’s design…

<Image src="https://i.imgur.com/9ANIKiZ.png" alt="Variants of the gift emoji" caption="The gift emoji, displayed by different devices." />


## The Workaround

Fortunately, whether you are a web, mobile or software developer, there is a **quick and easy** workaround for this problem, and that is [Twemoji](https://twemoji.twitter.com/).

![Spongebob and Patrick happy](https://miro.medium.com/max/625/0*BjQnY7Flwat1f-fP.gif)

This open source project by [Twitter](http://twitter.com/) converts Unicode emoji characters into normal [SVG](https://en.wikipedia.org/wiki/Scalable_Vector_Graphics) images, which are icons you can enlarge **as much as you like without losing any quality** — also known as vector images.

This way, your emojis will be **displayed in the same way on all devices** that are able to display images — which means, any smartphone and PC.

Now let’s dive into a concrete example. We’ll use the *Twemoji* library into our web application.

### 1. The HTML Code

```html
<h1>
  I'm a pretty header! 🎉
</h1>

<script src="https://twemoji.maxcdn.com/v/latest/twemoji.min.js" crossorigin="anonymous"></script>
<script src="app.js"></script>
```

### 2. The JavaScript Code

```js
twemoji.parse(document.body)
```
> Yes, that’s all you need! 😉

### 3. Adding A Bit Of Style

The previous code will create a new `<img>` element, with the `emoji` class.

```html
<img draggable="false" class="emoji" alt="🎉" src="https://twemoji.maxcdn.com/v/13.0.1/72x72/1f389.png">
```

However, if we don’t add any CSS styles, this is what the output looks like…

![Heading with oversized emoji](https://i.imgur.com/ezL6uJr.png)

Hence, just add these 6 lines to your CSS file:
```css
.emoji {
  display: inline-block;
  width: 1em;
  height: 1em;
  vertical-align: -.1em;
}
```
> We set the width and height the same as the surrounding text, and vertically center the emoji.

And now see the final output…

![Heading with emoji as image](https://i.imgur.com/9qsTzwf.png)

This is how your emoji will look like **on all devices** using your application. Awesome! Right?


## Caveats

When using this library, you have to be aware that it will create additional requests. Indeed, the output code is an `<img>` tag, with a source attribute to the Twemoji's MaxCDN url.

This can be problematic if you want your application to be quickly loaded through poor internet connections.

Also, the Twemojis appearance may not be to everyone's liking.


## Wrapping Up

**Accessibility is important**: your users should be able to see any content of your application. The little trick we’ve seen in this article is in fact used in [Discord](https://discord.app/) applications, and also in other famous ones — even Twitter itself.

Now, you can showcase your brand-new projects to your grandparents, **no matter what old device** they are using. 😏

![Grandma dancing](https://media.giphy.com/media/SYLxVuYVxMjAU9uZUK/giphy.gif)


.css-b3pn3b{display:inline-block;position:relative;}My Articles.css-1c50u9e{display:block;position:absolute;background:var(--chakra-colors-gray-200);width:100%;height:1px;bottom:calc(var(--chakra-space-2) * -1);}

My Articles