DEV Community: Huzaima Khan

Debounce search in react

Huzaima Khan — Sun, 19 Mar 2023 01:39:21 +0000

Debounce search in react is a useful technique for improving the performance of search functionality. Searching is an essential feature for many applications, but it can put a lot of strain on a system if not implemented properly. In this article, we will explore how debounce search can improve the performance and user experience of your React app. Debouncing is a technique that limits the rate at which a search function is executed, allowing the system to process user input in a more efficient and responsive manner. By the end of this article, you will have a clear understanding of debounce search and know how to implement it in your React application.

What is debounce?

Debounce is a technique used to improve the performance of a system by limiting the rate at which a particular function or event is executed. It works by delaying the execution of a function or event until a certain amount of time has passed without that function or event being triggered again. This can prevent excessive or unnecessary processing and reduce the workload on the system. Debouncing is commonly used in situations where a user is interacting with a system, such as when typing on a keyboard or clicking on a button, to ensure that the system only responds to the user's actions in a reasonable and smooth manner.

How to implement debounce?

To implement debounce in React, you can use the lodash library, which provides a convenient debounce function. First, you will need to install lodash by running the following command:

npm install lodash

Once lodash is installed, you can import the debounce function in your React component like this:

import debounce from "lodash/debounce";

Next, you will need to define a handleSearch function responsible for executing the search. This function should take the search query as an argument and use it to fetch the search results from your API or database.

function handleSearch(query) {
  // fetch search results from API or database
}

Now, you can use the debounce function to wrap the handleSearch function and specify the time to wait before executing it. It's also a good idea to use useCallback so the function is memoized. And since handleSearch is defined outside the component, we don't need to add it to the dependency array. For example, the following code will wait for 500 milliseconds before executing the handleSearch function:

const debouncedHandleSearch = useCallback(debounce(handleSearch, timeout), []);

Finally, you can use the debouncedHandleSearch function in your React component's render method. For example, you could use an input element with an onChange event handler that calls the debouncedHandleSearch function like this:

render() {
  return (
    <input
      type="text"
      onChange={(e) => debouncedHandleSearch(e.target.value)}
    />
  );
}

This will create a debounced search that executes only after the user has stopped typing for 500 milliseconds. You can adjust this time interval to suit your specific needs.

Debounce is a valuable technique for improving search performance in React applications. By delaying the execution of the search until the user has finished typing, you can improve the performance of your application and provide a better user experience.

Lazy Loading React Components using intersection observer

Huzaima Khan — Tue, 17 Jan 2023 12:59:52 +0000

Lazy loading react components is a way of deferring the rendering of components until they're needed. For below-the-fold content, it often makes sense to lazy load components, especially if they're detrimental to the performance if loaded upfront. I personally prefer to do lazy load heavy images and videos which appear below the fold. It helps increase core web vitals.

What is intersection observer?

An intersection observer is a JavaScript API that allows you to monitor when an element in your web page enters or exits the viewport. This can be useful for various purposes, such as triggering animations, lazy loading content, or implementing infinite scroll. The intersection observer API works by setting up a "callback" function that is executed whenever the target element intersects with the viewport, allowing you to respond to these events in your code.

Browser support for intersection observer

The intersection observer API is supported by most modern web browsers, including Chrome, Firefox, Safari, and Edge. However, it may not be supported by older browsers or some mobile browsers. You can check the specific browser support for the intersection observer API on caniuse.com, which tracks browser support for different web technologies. If your target browser don't support it, you can polyfill (add support for) the API in order to use it in your code.

Lazy Loading React Components using intersection observer (the hard way)

To use the intersection observer API in React, you can use the useRef hook to create a reference to the element you want to monitor and the useEffect hook to set up the observer. Here is an example of how you might do this:

function MyComponent() {
  // Create a reference to the element that we want to observe
  const targetElement = useRef(null);
  const [isInView, setIsInView] = useState(false);

  // Set up the intersection observer when the component mounts
  useEffect(() => {
    const observer = new IntersectionObserver(onIntersection, {});
    observer.observe(targetElement.current);

    // Clean up the observer when the component unmounts
    return () => observer.unobserve(targetElement.current);
  }, []);

  // This is the callback function that is executed whenever the
  // target element intersects with the viewport
  function onIntersection(entries) {
    // Do something with the intersection data, such as triggering
    // an animation or lazy loading content
    setIsInView(true);
  }

  return (
    <div ref={targetElement}>{isInView ? <VeryHeavyComponent /> : null}</div>
  );
}

In this example, we used the useRef hook to create a reference to the element we want to observe and the useEffect hook to set up the intersection observer when the component mounts. When the target element intersects with the viewport, the onIntersection callback function is executed, allowing you to respond to the event in your code.

Make sure to clean up the IntersectionObserver you subscribed in useEffect. It's an important optimization of useEffect

Lazy Loading React Components using intersection observer (the easy way)

The react-intersection-observer package is a wrapper around the IntersectionObserver API and makes lazy loading less verbose and easy-peasy. Let's take a look at an example:

const Video = (props) => {
  const { ref, inView } = useInView({
    triggerOnce: true,
    fallbackInView: true,
  });

  return <div ref={ref}>{inView ? <video {...props} /> : null}</div>;
};

In this example, the Video component is a wrapper around HTML's native video element. We only render video when it is in the viewport. It helps boost the performance of the page and core web vitals. You can pass various configurations to the useInView hook as described in the documentation. For example, you can specify a threshold value to control when the component should be considered visible or add a root margin to adjust the boundaries of the viewport.

In conclusion, using the IntersectionObserver API or react-intersection-observer package allows us to implement lazy loading in React components. This can improve the performance of our application by delaying the rendering of heavy components until they are actually needed. By using the useInView hook and monitoring when a component enters the viewport, we can efficiently lazy load our components and improve the user experience.

Optimizing useEffect in React

Huzaima Khan — Sat, 10 Dec 2022 11:35:35 +0000

Originally published at https://huzaima.io.

useEffect is one of the most widely used hooks in React. Optimizing useEffect in React gives you a significant boost in performance and sometimes gets your code rid of nasty bugs. I've encountered many situations where there were performance issues or some difficult-to-find bugs due to incorrect usage of useEffect. Here I'll discuss a few of the optimization patterns which are very easy to adhere to yet very effective.

1. Use primitives in the dependency array

We often pass JavaScript objects in the useEffect dependency array. Although nothing is wrong with doing that, sometimes it makes more sense to destructure the JavaScript object and only pass the specific value to the dependency array of useEffect. Let's take a look at an example. Suppose we have a UserInfo component which takes the user object as a prop and fetches the user's transaction data whenever the user changes. We need to only get the user's transaction data when the user changes. Our user object looks like this:

{
  "id": 123,
  "name": "John Doe",
  "imageURL": "...",
  "isActive": false
}

The typical implementation will look like this:

function UserInfo({ user }) {

  useEffect(() => {
    getUserData(user.id);
  }, [user]);

  return (
    ...
  );
}

This will get user data from the server whenever the user object changes. But looking at the user object, it only makes sense to get the new data when the user.id changes. There could be instances where the user's data changes but the id don't, which won't benefit us in making an API call and getting the data from the server again. Let's say the user's isActive was false initially and later changed to true. In this case, we don't need to get the user's transaction data again because the user is still the same. We can avoid this redundant API call by changing our useEffect dependencies. Here's the refactored component using primitive data types:

function UserInfo({ user }) {
  const { id } = user;

  useEffect(() => {
    getUserData(id);
  }, [id]);

  return (
    ...
  );
}

With the above optimization of useEffect, we will only get the user's transactional data when the user id changes. Remember, in useEffect dependencies, non-primitives (like objects and arrays) are checked for equality only by reference, not by the value. So the following code will always return false:

{ name: "Huzaima" } === { name: "Huzaima" }

2. Avoid needless dependencies

Sometimes, we use useEffect to derive a new state from our current state. Suppose we've a counter which totals the length of the string every time the input value is updated. We can implement that like this:

function CharacterCounter() {
  const [inputValue, setInputValue] = useState("");
  const [compoundStringLength, setCompoundStringLength] = useState(0);

  useEffect(() => {
    if (inputValue) {
      setCompoundStringLength(compoundStringLength + inputValue.length);
    }
  }, [inputValue, compoundStringLength]);

  return (
    ...
  );
}

The above code results in useEffect being executed infinitely. Why? Because of the incorrect dependency. We're updating compoundStringLength inside the useEffect and using the same as a dependency. How do we solve this problem? We need to use compoundStringLength inside the useEffect for computation, so we can't get rid of it. But what we can do is remove it from the dependency array. You might think this will result in an incorrect value of compoundStringLength due to useEffect being a closure. You're right... and wrong. This is correct because useEffect is a closure, so we won't get the correct value of compoundStringLength if we don't use it in the dependency array. Still, there's a way of getting the correct value of compoundStringLength without specifying it in the dependency array. The state setter function (setCompoundStringLength) doesn't only accept value but also a function. The signature of that function looks like this:

setCompoundStringLength: (currentStateValue) => newStateValue;

We can leverage the above function signature in the useEffect to get the correct value of compoundStringLength for our computations without specifying it as a dependency. The refactored optimization of useEffect looks like this:

function CharacterCounter() {
  const [inputValue, setInputValue] = useState("");
  const [compoundStringLength, setCompoundStringLength] = useState(0);

  useEffect(() => {
    if (inputValue) {
      setCompoundStringLength(
        (compoundStringLength) => compoundStringLength + inputValue.length
      );
    }
  }, [inputValue]);

  return (
    ...
  );
}

3. Hoist functions

Any unmemoized function that you define inside the component is recreated on every render. A very naive example is this:

function EmailValidate() {
  const [email, setEmail] = useState("");

  const isEmailValid = (input) => {
    const regex =
      /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;

    if (regex.test(input)) return "Email is valid";
    return "Email is invalid";
  };

  return (
    <>
      <input value={email} onChange={(event) => setEmail(event.target.value)} />
      <p>{isEmailValid(email)}</p>
    </>
  );
}

Here you can see that the isEmailValid function is a pure function and doesn't depend on the component's props and/or state. We can easily optimize this by extracting the function outside the component. Rewriting the above component will look like this:

const isEmailValid = (input) => {
  const regex =
    /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;

  if (regex.test(input)) return "Email is valid";
  return "Email is invalid";
};

function EmailValidate() {
  const [email, setEmail] = useState("");

  return (
    <>
      <input value={email} onChange={(event) => setEmail(event.target.value)} />
      <p>{isEmailValid(email)}</p>
    </>
  );
}

4. Clean up

The primary purpose of useEffect is to handle side effects. Sometimes you have to clean up those side effects like event handler subscriptions or observables. You can return the function having clean-up logic from the function inside useEffect. Let us take an example of an input field which should clear when the user presses the Escape key. We can do so like this:

function Input() {
  const [input, setInput] = useState("");

  const escFunction = useCallback((event) => {
    if (event.key === "Escape") {
      setInput("");
    }
  }, []);

  useEffect(() => {
    document.addEventListener("keydown", escFunction, false);

    return () => {
      document.removeEventListener("keydown", escFunction, false);
    };
  }, [escFunction]);

  return (
    <>
      <input value={input} onChange={(event) => setInput(event.target.value)} />
    </>
  );
}

In the above code, we're returning a function from inside the useEffect. That function unsubscribes the keydown event listener, saving us from nasty memory leak problems.

5. Use multiple effects to separate concerns

Ever heard of divide and conquer? Yup! That's precisely what we need to do here. Aka separation of concerns, a widely practiced principle in software engineering. React team advocates for separation of concerns in useEffect, i.e. using different useEffect for every use case. Suppose we've a component which gets userId and organizationId in props. We make an API call to get user and organization data based on the props. We can write useEffect like this:

useEffect(() => {
  getUser(userId);
  getOrganization(organizationId);
}, [userId, organizationId]);

The above useEffect will work fine. But there's one fundamental problem. If the userId change but the organizationId don't, getOrganization will still get called. Why? Because we've added two separate concerns in a single useEffect. We need to segregate them into two different useEffect. We can rewrite it like this:

useEffect(() => {
  getUser(userId);
}, [userId]);

useEffect(() => {
  getOrganization(organizationId);
}, [organizationId]);

6. Custom hooks

Custom hooks are a great way of extracting side effects, which can be reused by many other components. It's also an elegant way of organizing your code. Suppose we've a custom hook to return details about the input string. We can write that custom hook like this:

function useStringDescription(inputValue) {
  if (!inputValue) {
    return defaultValue;
  } else {
    const wordCount = inputValue.trim().split(/\s+/).length;
    const noOfVowels = inputValue.match(/[aeiou]/gi)?.length || 0;
    return {
      wordCount,
      noOfVowels,
    };
  }
}

The useStringDescription hook returns the number of vowels and the word count of a string passed in the argument. We can use this hook like this:

function App() {
  const [inputValue, setInputValue] = useState("");
  const stringDescription = useStringDescription(inputValue);
  const { wordCount, noOfVowels } = stringDescription;

  useEffect(() => {
    console.log("stringDescription changed", stringDescription);
  }, [stringDescription]);

  return (
    ...
  );
}

Let's try to use the above setup and see how many times the useEffect is executed.

You can see that useEffect is called even when the stringDescription object's value doesn't change. We can destructure the stringDescription object as defined in the 1st rule of this article, or we can optimize our custom hook like this:

function useStringDescription(inputValue) {
  const [stringDescription, setStringDescription] = useState(defaultValue);

  useEffect(() => {
    if (!inputValue) {
      setStringDescription(defaultValue);
    } else {
      const wordCount = inputValue.trim().split(/\s+/).length;
      const noOfVowels = inputValue.match(/[aeiou]/gi)?.length || 0;

      if (
        wordCount !== stringDescription.wordCount ||
        noOfVowels !== stringDescription.noOfVowels
      ) {
        setStringDescription({
          wordCount,
          noOfVowels,
        });
      }
    }
  }, [inputValue, stringDescription.noOfVowels, stringDescription.wordCount]);

  return stringDescription;
}

Now, we're updating the state when any value changes. Let's check out the results:

See? useEffect didn't get called needlessly because the referential equality holds.

These were the bunch of useEffect optimizations we can use to make the usage of hooks more effective and get rid of nasty and notoriously hard to find bugs caused due to incorrect usage of hooks. Optimizing useEffect in React also gives you a boost in performance. What are your secret useEffect recipes? Let me know on twitter. And don't forget to read my previous blog about promise speed up.

Speed up Promises in JavaScript

Huzaima Khan — Mon, 08 Aug 2022 07:44:00 +0000

Promises are an integral part of async code in JavaScript. We often come across the need to run multiple promises at a time that are independent of each other. We can achieve this by using JavaScript's Promise.all. Promise.all is a promise provided by JavaScript that accepts an array of promises and resolves when all of them get resolved.

Suppose you've to fetch data from 3 different APIs. Each API takes around 3 seconds to respond. A normal code without concurrency would look like this:

async function fetchData() {
  const metadata = await getMetadata(); 
  const products = await getProducts();
  const categories = await getCategories();

  return { metadata, products, categories };
}

The code above works fine. But can be improved by leveraging concurrency. We don't need to run them sequentially since all the three functions are independent of each other. We don't need metadata before products. We can rewrite the above code snippets like this:

async function fetchData() {
  const metadata = getMetadata();
  const products = getProducts();
  const categories = getCategories();

  return await Promise.all([
    metadata,
    products,
    categories,
  ]);
}

Now we're not waiting for metadata before products. Instead, all the data gets fetched simultaneously. This technique is quite powerful and speed-up your code. This technique can also fetch the data based on a certain input. Suppose you want to fetch product details for a list of products. You can refactor your promises like this:

async function fetchProductDetails(ids) {
  const productDetails = await Promise.all(
    ids.map(id => getProduct(id))
  );
  return productDetails;
}

As JavaScript is single-threaded, parallelism cannot be achieved unless you create a child process for each promise. Spawning a process is a costly operation and there are certain overheads which make it less viable. Promise.all is a good alternative to achieve concurrency and speed up your code. Again, it depends upon the problem you're trying to solve. What techniques do you have to speed up promises in JavaScript?