DEV Community: Ludal 🚀

ASDF: Automatic Management of Multiple Versions

Ludal 🚀 — Mon, 18 Apr 2022 14:31:05 +0000

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
ASDF: Our Magic Wand
An Example
Setting Up ASDF
Usage
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.



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

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 really interesting 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 alert: it is ridiculously easy).

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

If you are on MacOS, you can simply use brew.
brew install asdf

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

💡 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

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 sub-directories. 🥳

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

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

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

💡 You can also specify a version for the current shell.
asdf shell nodejs 17.3.0

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:

Install the corresponding plugin: asdf plugin add [plugin]
Install all the versions you need: asdf install [plugin] [version]
Select the local version for each concerned project: asdf local [plugin] [version]
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. Also, feel free to star the GitHub Repository 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. 🤘🏼

Custom React Hooks: useInView

Ludal 🚀 ・ Feb 26 '22

Why Your GitHub Profile Sucks?

Ludal 🚀 ・ Feb 3 '21

#github #tips #profile #design

Taking console.log To The Next Level

Ludal 🚀 ・ Apr 29 '21

#javascript

Custom React Hooks: useInView

Ludal 🚀 — Sat, 26 Feb 2022 17:00:10 +0000

Last time, we’ve seen how to implement the useAudio Hook to simplify sounds management within our React apps. Today, let’s see how to create a Hook that tracks the visibility our components on the screen: useInView.

Motivation
Implementation
Usage
Wrapping Up

Motivation

First of all, 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 of 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 that wait for a given element to be above a given “threshold” (called the root margin), as shown in the figure below.

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



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:



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

Each key of the options object is optional.

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.



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

...

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

Note that the options parameter is optional, and could be omitted.

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



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

Then, we are going to setup 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:



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.



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.



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.



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

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

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

ℹ️ We are using the optional chaining operator (?.) to prevent from errors if for some reasons the observer is still null.

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.



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.



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.



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

Ludal 🚀Follow

French junior DevOps engineer, based in Lille. 🇫🇷 Mainly writing about DevOps and CyberSecurity. 👨🏻‍💻

Custom React Hooks: useAudio

Ludal 🚀 — Tue, 11 Jan 2022 15:44:59 +0000

In the last episode of the Custom React Hooks series, we’ve discovered the useNetworkState hook to simplify the user’s network state management. Today, we’ll explore another useful custom hook: useAudio. Ready? Let’s go!

Motivation
Implementation
Usage
Conclusion
Support Me

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 (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 bit, you might hear a switch sound. This sound comes from this custom hook. The second example is the Typospeed game (not self-promotion either), where you can hear sounds when removing a word (actually, Typospeed was built with Svelte, 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...



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>
  )
}

👎 We don’t want 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.

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.



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.



audio.play()
audio.pause()

Hence the skeleton will look like this:



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:



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
}

ℹ️ 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).

Our hook is now ready to be used. 🤘

Usage

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



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.

Conclusion

I hope this hook will be useful to you for your projects. If you have any questions, feel free to ask them in the comments section. With that being said, thank you for reading me, and I’ll see you next time for a new custom hook. 🤗

Source code available on CodeSanbox.

Support Me

If you wish to support me, you can click the following link to buy me a coffee (which I will then probably turn into a new custom hook... ☕).

Custom React Hooks: useNetworkState

Ludal 🚀 — Sun, 28 Nov 2021 16:05:34 +0000

In the last episode of the Custom React Hooks series, we've implemented the useLocalStorage hook to simplify local storage management. In today's episode, we'll create a hook to simplify the observation of our users network state: useNetworkState.

Motivation
Implementation
Usage
Conclusion
Support Me

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 toast message informing it to check its network connectivity. To do this in a React app, here's how you could proceed:

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:

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:

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 link, that will bring you to my article on the useBoolean hook.

Note: if you don't want to use the useBoolean hook, you can be satisfied with the native useState one, and useNetworkState would be the following:

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):

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? 😎

All the logic is now abstracted outside of the component, that only focuses on what matters to it. By doing this, we're following the SOC (Separation of Concerns) design principle — more information here.

Conclusion

I hope this hook will be useful to you for your projects. If you have any questions, feel free to ask them in the comments section. For now, thanks for reading me, and see you next time for a new custom hook. 🤗

Source code available on CodeSanbox.

Support Me

If you wish to support me, you can click the following link to buy me a coffee (which I will then probably turn into a new custom hook... ☕).

Custom React Hooks: useLocalStorage

Ludal 🚀 — Sun, 07 Nov 2021 18:46:27 +0000

In the last episode of the Custom React Hooks series, we've implemented the useArray hook to simplify arrays management. In today's episode, we'll create a hook to simplify the local storage management: useLocalStorage.

Motivation
Implementation
Usage
Improvement Ideas
Conclusion

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, settings...). To save the config, you'll use an object that could look like this:



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

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

And the corresponding source code could be similar to this:



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}
            />
        </>
    );
};

But 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 userLocalStorage hook, we'll 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, as this will become the hook's job.

Implementation

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



// 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));

So our hook signature could look like this:



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 be set to null. We would like 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 a new optional argument: the default value.



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

We're now ready to start implementing the hook. First, we'll read the local storage value corresponding to our key parameter. If it doesn't exist, we'll return the default value.



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

Great! We've made the first step of the implementation. Now, 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.



const useLocalStorage = (key, defaultValue = null) => {
    const [value, setValue] = useState(() => {
        try {
            const saved = localStorage.getItem(key);
            if (saved !== null) {
                return JSON.parse(saved);
            }
            return defaultValue;
        } catch {
            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. We'll use the useEffect hook to do so.



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

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

⚠️ Be aware that the JSON.stringify method can also throw errors. However, this time, it is not the job of this hook to handle those errors — except if you want to catch them in order to throw a custom one.

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.



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.



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

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

    return [value, setValue];
};

Are we done now? Well, yes... and no. Why not? Because you can customize this hook the way you want! 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 to 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. Thanks to it, we don't have to synchronize anything anymore. Here's how the code will now look like:



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>

  <span class="p">&lt;</span><span class="nt">label</span> <span class="na">htmlFor</span><span class="p">=</span><span class="s">"pushNotifications"</span><span class="p">&gt;</span>Push Notifications<span class="p">&lt;/</span><span class="nt">label</span><span class="p">&gt;</span>
  <span class="p">&lt;</span><span class="nt">input</span>
    <span class="na">type</span><span class="p">=</span><span class="s">"checkbox"</span>
    <span class="na">id</span><span class="p">=</span><span class="s">"pushNotifications"</span>
    <span class="na">checked</span><span class="p">=</span><span class="si">{</span><span class="nx">config</span><span class="p">.</span><span class="nx">settings</span><span class="p">.</span><span class="nx">pushNotifications</span><span class="si">}</span>
    <span class="na">onChange</span><span class="p">=</span><span class="si">{</span><span class="nx">handleChange</span><span class="si">}</span>
  <span class="p">/&gt;</span>
<span class="p">&lt;/&gt;</span>



);

};

Improvement Ideas

Handle exceptions of the JSON.stringify method if you need to
If the value becomes null, clear the local storage key (with localStorage.removeItem)
If the key changes, remove the value associated with the old key to avoid using storage space unnecessarily

Conclusion

I hope this hook will be useful to you for your projects. If you have any questions, feel free to ask them in the comments section.

Thanks for reading me, and see you next time for a new custom hook. 🤗

Source code available on CodeSandbox.

Support Me

If you wish to support me, you can buy me a coffee with the following link (I will then probably turn that coffee into a new custom hook... ☕)

Custom React Hooks: useArray

Ludal 🚀 — Sun, 31 Oct 2021 16:14:00 +0000

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
Implementation
Usage
Improvement Ideas
Conclusion

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:

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

Then, you'd have a removeTask function, that could look like this:

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.

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

  return { value, setValue }
}

Then we'll add the push function to add an element at the end of the array.

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

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

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.

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

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

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

Example:

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:

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 of improvements 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

Conclusion

I hope this hook will be useful to you for your future (or existing) projects. If you have any questions, feel free to ask them in the comments section.

Thanks for reading me, and see you next time for a new custom hook. 🤗

Source code available on CodeSandbox.

Support Me

If you wish to support me, you can buy me a coffee with the following link (I will then probably turn that coffee into a new custom hook... ☕)

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

Ludal 🚀 — Thu, 28 Oct 2021 15:21:13 +0000

You may already know how to add a README to your GitHub profile (if you don't, have a look at this article), but did you know 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.

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

⚠️ Make sure to set the repository's visibility to public.

From there, the only thing you have to do is creating a profile/README.md file within this repository, that will show up in the organization homepage.

⚠️ Make sure to create the README.md within the profile directory.

And here's the final result, on the organization's GitHub homepage:

Why Your GitHub Profile Sucks?

Ludal 🚀 ・ Feb 3 '21 ・ 5 min read

#github #tips #profile #design

Custom React Hooks: useCounter

Ludal 🚀 ・ Oct 10 '21 ・ 3 min read

#react #javascript #programming

References

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

Custom React Hooks: useCounter

Ludal 🚀 — Sun, 10 Oct 2021 13:18:09 +0000

In the last article of the Custom React Hooks series, we've implemented the useBoolean hook. Today, we'll create a not more complicated one: useCounter. As its name suggests, this hook will help us manage a counter state thanks to utility functions, such as increment and decrement. 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 he wants. This is how the user interface might look like (let's forget the style):

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

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>
  );
}

ℹ️ Of course, all the examples and code snippets will be extremely simplified in order to only focus on what matters the most in this article.

The above component could be simplified by introducing a custom useCounter hook:

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>
  );
}

Sounds interesting? Let's implement this hook! 😎

Implementation

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

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 creating new functions at every render, more info here). In our case, the component is so simple that calling useCallback 3 times to improve performances 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 onClick event.

ℹ️ For more information, don't hesitate to have a look at this article from Dmitri Pavlutin, 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).

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

Improvement ideas

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

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

Conclusion

So far, the custom hooks we've been creating are very simple. In the next articles, we'll start implementing more complex hooks to really help us simplify our components code and avoid code duplication. That being said, thanks for reading me. I hope you enjoyed this article. If you did, don't hesitate to have a look at my other ones. Also, feel free to write some comments if you have any questions or remarks. 🤗

Source Code available on CodeSandbox

Support Me

If you wish to support me, you can buy me a coffee with the following link (I will then probably turn that coffee into a new custom hook... ☕)

Custom React Hooks: useBoolean

Ludal 🚀 — Tue, 05 Oct 2021 19:18:39 +0000

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 article is that we can implement our own custom hooks, using the few primitives hooks React provides us, like useState and useEffect. This way, you can drastically reduce the cognitive complexity of your components, by moving away some logic into functions that you will be able to reuse anywhere in the other components of your React applications. Your code will look cleaner, and you're 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 of all, why are we going to implement such a hook? Let's have a look at this simple component:



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

  return (
    <div className="spoil">
      <button onClick={() => setShowSpoil((visible) => !visible)}>
        {showSpoil ? "Hide" : "Show"}
      </button>
      {showSpoil && <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. Of course, clicking the button again will hide it back, and so on.

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



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:



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.



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

    return [value, setValue]
}

⚠️ Be careful: you'll only be able to use the useBoolean function (or should I say hook) in React components, as it uses the useState hook.

So far, we've just created an alias for the useState hook.

Not very useful...😅

The interesting part comes now: instead of having the setValue function in the return array, we will use 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:



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]
}

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

Usage



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

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

    return ...
}

⚠️ Be careful: you can't use setIsLoading(true) as we don't export a function anymore but an object.

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

Conclusion

Thanks for reading me. I hope you enjoyed this article, and if that's the case, don't hesitate to have a look at my other ones. Also, feel free to post some comments if you have any questions, or if you just want to say "hi". 👋

Support Me

If you wish to support me, you can buy me a coffee with the following link (I will then probably turn that coffee into a new custom hook... ☕)

References

https://reactjs.org/docs/hooks-overview.html

https://en.wikipedia.org/wiki/Single-responsibility_principle

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

Ludal 🚀 — Fri, 14 May 2021 15:50:17 +0000

At some point in your Javascript developer journey, you've certainly encountered these types of imports:

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

And you were probably bothered by the ugliness of them...

But guess what? I'm here as a savior to show you how to get rid of them! (really) 😎

Ready? Let's go! 🏁

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.

Let's complete it with the following keys:

{
    "compilerOptions": {
        "baseUrl": "."
    }
}

Now, the most studious ones of you might think: "Compiler options? But JavaScript is not a compiled language!". And you're right! If you want to know why does this key exist, I recommend you to follow this link 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:

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

Without this configuration, here's how you would have done it:

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

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 able to import them relatively from the current directory you are in!

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


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

Paths

Back to our jsconfig.json. You 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.

{
    "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:

// header.js
import 'css/header.css'

But I wouldn't recommend doing this at all, as this would create inconsistencies between the real folders' names and the aliases — instead, why not simply renaming the actual folder? 🤨

Nevertheless, this option can be useful for folders you often use and that are not at the root of your project. Let's consider the following structure:

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

We will often use the styles directory to import our styles, and that could be very handy if we could remove the assets prefix, in order to not have to always write this:

import 'assets/styles/index.css'

In that case, you could add the following to your jsconfig.json:

{
    "compilerOptions": {
        "baseUrl": ".",
        "paths": {
            "@styles/*": ["assets/styles/*"]
        }
    }
}

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

import '@styles/index.css'

The @ is a conventional way to reference a folder-mapping import, in order to differentiate it from a classic import.

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

Exactly! Inside the tsconfig.json file. Smart, isn't it? 😏

Conclusion

That's it! You've now got rid of those awful imports, congratulations! 🎉

To go further, I would recommend you following this link from the official Visual Studio Code website, in particular to exclude some directories that are not part of the source code.

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

Taking console.log To The Next Level

Ludal 🚀 — Thu, 29 Apr 2021 18:53:05 +0000

As a JavaScript developer, you are obviously familiar with this extremely powerful debugging tool, which is... console.log. 🙄

But are you really using it to its full potential? In this article, I'll show you how powerful and impressive this tool can be.

Arrays And Objects

Let's start with the basics. When working with arrays, the first thing you can do is simply logging them with the default log method on the console object.

const fruits = ['🍎', '🍐', '🍌', '🥝']
console.log(fruits)

And here's the output:

But what if you're working with a 2 dimensional array?

const foods = [['🍎', '🍐', '🍌', '🥝'], ['🥕', '🥔', '🥦', '🧄']]
console.log(foods)

Output:

Not very convenient...

Now, you can either click the arrow on the left of the (2), or use another method of the consoleobject, which is: table.

console.table(foods)

This outputs the following table:

This table contains as much rows as the number of arrays contained by the parent one (here, 2).

You now get a more user-friendly display of that 2 dimensional array! 💃

When dealing with objects, here's another trick you can do to enhance your loggings:

const user = {name: "Jim", age: 18, country: "USA"}
console.log("Logged in user : %o", user)

This command displays the following:

Adding Styles

So far, we've seen how we can display arrays and objects in a more beautiful way. Now, something most of us don't know about, is that we can add styles to our logs. 🎨

Don't believe me? Here's how:

console.log("%cHello, world!", "color: green; font-weight: bold; font-size: 1.5em")

How does this work? Everything after the %c will have the styles passed in the second parameter of the console.log method applied to it. These are CSS styles, that you pass as a string, as you would use them inside the style attribute in HTML.

Thus, here's the output:

You can have different styles for the same text:

You can also add borders, paddings, border-radius...

Dazzling, isn't it? 😏

But... why would you want to add styles to a console message? 🤨

According to me, the two reasons you might want to use this are either to have fun (when you discover you can do this) or to add Easter eggs to your application. Here are some examples:

NB: this is not my YouTube channel. 😉

For a complete list of all the CSS properties you can use, just refer to the MDN.

Errors And Warnings

At some point in your code, you might want to display text in a different way than the basic one. If you've ever opened the dev tools in a popular website (such as YouTube, Facebook...), you might have noticed those different types of messages:

But did you know that you can also do this? And guess what: that's as easy as console.log!

There are different methods for that:

console.error for error messages
console.warn for warning messages

How to use them? The same way as you use console.log! 🤩

Conclusion

As we've seen in this article, we can enhance our logging messages with features most of us didn't know about! These features maybe be gadgets, and you might not need to use them frequently, but they can be useful in some situations. So it's always good to know them!

And hey, you can show off to your friends. 😎

That being said, don't forget to remove your console.log from your code when using production environment, as these methods are development tools! 😉

Thanks for reading this article. ♥

Discord: Deleting Multiple Messages At Once

Ludal 🚀 — Thu, 11 Feb 2021 18:21:08 +0000

Lately I had to remove several message at once on Discord, but I figured out how painful that was.

This is because I didn't know about this tip.

1. How To Delete A Message

I'm pretty sure you already know how to do delete a message, but let's think about it: to remove a single message, it requires you 3 clicks:

Now imagine that you want to delete dozens of messages (for instance, bot commands), then it can quickly get painful. 😓

2. The solution

There's a hack for deleting multiple messages at once, and this is: just hold your Shift key while hovering messages. Here's how the options panel will now look like:

Now from here, you just have to click the trash icon for your message to be remove. You won't need to confirm the removal anymore: once you've click this button, your message is deleted. 🥳

Conclusion

I hope this article was useful for you!

If so, don't hesitate to leave a ❤️ and to follow me. 🤗

You Are Using Emojis The Wrong Way

Ludal 🚀 ・ Jan 27 '21 ・ 3 min read

#webdev #mobile #a11y #twitter

DEV Community: Ludal 🚀

ASDF: Automatic Management of Multiple Versions

Setting the Scene

ASDF: Our Magic Wand

An Example

Setting Up ASDF

Usage

Wrapping Up

More Articles From Me

Custom React Hooks: useInView

Ludal 🚀 ・ Feb 26 '22

Why Your GitHub Profile Sucks?

Ludal 🚀 ・ Feb 3 '21

Taking console.log To The Next Level

Ludal 🚀 ・ Apr 29 '21

Custom React Hooks: useInView

Motivation

Implementation

Usage

Wrapping Up

Ludal 🚀Follow

Custom React Hooks: useAudio

Motivation

Implementation

Usage

Conclusion

Support Me

Custom React Hooks: useNetworkState

Motivation

Implementation

Usage

Conclusion

Support Me

Custom React Hooks: useLocalStorage

Motivation

Implementation

Usage

Improvement Ideas

Conclusion

Support Me

Custom React Hooks: useArray

Motivation

Implementation

Usage

Improvement Ideas

Conclusion

Support Me

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

Other Articles by Me

Why Your GitHub Profile Sucks?

Ludal 🚀 ・ Feb 3 '21 ・ 5 min read

Custom React Hooks: useCounter

Ludal 🚀 ・ Oct 10 '21 ・ 3 min read

References

Custom React Hooks: useCounter

Motivation

Implementation

Improvement ideas

Conclusion

Support Me

Custom React Hooks: useBoolean

Motivation

Implementation

Usage

Conclusion

Support Me

References

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

baseUrl

Paths

TypeScript

Conclusion

Taking console.log To The Next Level

Arrays And Objects

Adding Styles

Errors And Warnings

Conclusion

Discord: Deleting Multiple Messages At Once

1. How To Delete A Message

2. The solution