DEV Community: Omar Moataz Attia

React Rapid Fire: How to Wait for useState to Execute?

Omar Moataz Attia — Mon, 12 Sep 2022 13:53:41 +0000

Ever wanted useState to update before you continue executing the rest of your code? When we used class components, we had a very useful callback on setState that allowed you to execute code after the state had updated. Let's look at some code just so you know what I'm talking about.



class Home extends React.Component {
  state = {
    counter: 1,
  };

  increment = () => {
    this.setState(
      (state: State) => ({
        counter: state.counter + 1,
      }),
      () => {
        console.log(this.state.counter);
      }
    );
  };

  render() {
    return <div onClick={this.increment}>{this.state.counter} </div>;
  }
}

Here, we are passing a callback to setState so that we're able to access the update counter right after the state update and here, we're guaranteed to have it be updated but what if we want to do the same thing with functional components and hooks.

Well, there isn't a direct alternative that has the same level of convenience but we do have an option in React hooks to the rescue: useEffect.

useEffect is one of those hooks that can be fairly called a jack of all trades but a master of none. It's not really the perfect fit for componentDidMount, componentDidUpdate, or componentWillUnmount but the advantage is that it can replace all of them I guess.

Here, we can use useEffect to listen for that state change and execute the code we wanted to execute in the callback. However, in this case, we're not really forcing react to update the state right away like we used to with class components but rather, we're listening for a change so that we can execute our code when it eventually happens. Let's look at the code



const Home: NextPage = () => {
  const [counter, setCounter] = useState(1);

  useEffect(() => {
    // here I am guaranteed to get the updated counter
    // since I waited for it to change.
    console.log(counter);
    // here we added counter to the dependency array to
    // listen for changes to that state variable.
  }, [counter]);

  const handleClick = () => {
    setCounter(counter => counter + 1);
  }

  return <div onClick={handleClick}> {counter} </div>
};

export default Home;

There is one difference between the 2 implementations to look at here:

useEffect will listen to every change to counter and execute the effect unlike the class component implementation which would only execute the code we want in the specific situation we're in. In this case, the callback in class components is more accurate with regards to when it executes.

If you would like to know more about useEffect, you can refer to the docs

If you'd like to dive deeper into hooks and writing your own hooks, I wrote an article explaining just that here

How to optimize for Largest Contentful Paint (LCP)?

Omar Moataz Attia — Sat, 03 Sep 2022 22:33:46 +0000

The answer, as with anything, is it depends! I know that's a
bit of a sit on the fence kind of answer but let's dive a bit deeper into it to figure out at least what to look for.

First, we need to be able to identify what the LCP element is. For that, we have 2 options: Local Lighthouse using chrome dev tools and Page Speed Insights (PSI) which allows you to do the same thing only for live or preproduction environments we might have. Each one has their use case. Local Lighthouse is useful when you're trying to verify that a fix actually works or that your build is not going to introduce a performance regression. PSI is useful if you want to figure out what your current performance is using a live URL.

Note: PSI also runs on the lighthouse engine, the difference is that the performance checks are run by Google servers so the runs are not dependent on your machine's performance unlike running lighthouse locally. This means that PSI scores tend to be more accurate because they're produced using a consistent synthetic environment.

If you're interested in all the different ways to run lighthouse, here's the perfect article for you by the folks at Google.

Now that we've figured out how to run a lighthouse performance test, let's try our hand at actually analyzing the results which, in this case, is really easy. If you scroll a bit through the lighthouse results, you'll easily be able to find the LCP element for a particular page like so:

Now that we've figured that out, how can we fix it? Well, we can first take a look at whether the LCP element is a text or image element because our solutions would definitely differ in each case but one thing is consistent with LCP, the less render-blocking JS or CSS you're loading, the better so it's useful to try and figure out what's being bundled and whether we can reduce it. (more on that later)

If the LCP element is an image, we can try rendering a smaller image for responsive formats because, usually, phones don't need as high of an image resolution as desktop so we need to serve smaller images based on device type. We can also serve images in progressive formats like WebP which can provide higher fidelity at lower cost than legacy formats like JPG and PNG. If you're worried about browser support for this format, you can check caniuse for compatibility with different browsers.

What if the LCP element is a text element? Well, we might want to look at how our font is being rendered. You see, if you're using a custom font, and the likelihood is that you probably are, you're requesting that font from somewhere which means that you're wasting time where the user doesn't see any text while the font is being fetched. To solve that problem, we need to show the default system font that's available locally first then switch it out for the custom font as soon as it loads. To do that, we can use the CSS font-display property which has 2 options of interest in this case: Block or Swap. In most cases, we should be using swap but if you're interested to learn more, here's a great summary of the trade-offs by Chris Coyer.

In this article, I summarized my thought process when it comes to debugging LCP issues and trying to fix them. This is by no means a definitive guide but rather meant as a starting point for your investigative journey into LCP performance.

What Are Core Web Vitals?

Omar Moataz Attia — Thu, 27 Jan 2022 11:04:08 +0000

What are core web vitals you ask? core web vitals are Google's new metrics for ranking performance. These numbers should matter to you if your business relies on discoverability by Search Engines, the most important of which being Google.

The folks at Google decided that, starting June 2021, they would start taking into account these performance metrics when they rank websites to show the user on Google search. That's not to say content doesn't matter. Content has and probably always will be king when it comes to search engines. However, we need to also start taking into account how our web pages perform with regards to speed and overall user experience.

Now, what are these metrics we need to focus on? Well, we have 3 that are considered the core pillars of performance: Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift. Let's look at what each one means individually!

Largest Contentful Paint (LCP) (measured in seconds):

It's the time it takes to load the largest element on the page. In most cases, if your website loads an image in the viewport then, it's likely to be the LCP element. Let's look at dev.to as an example on mobile.

Here you can see that the image takes up most of the space in the viewport so that's what we consider the LCP element.

Note: This is not the full device size. I cropped the image so that dev.to doesn't shrink it.

A few caveats:

LCP elements don't have to be an image, they can be text elements as well. As a result, the optimization techniques differ based on what the LCP element is.
From my experience, LCP elements are usually distinct elements that load on the page and not a group of elements on the page.
The LCP element is recalculated multiple times if the DOM elements change i.e. if an element loads early and then a massive image loads afterwards, a recalculation happens and now, the LCP element is the massive image rather than the element that loaded earlier.

First Input Delay (FID) (measured in seconds):

This is one of the simplest metrics to explain. It's basically the time it takes for your website to respond to user input after they click. In more technical terms, it's the time between the user interaction with the website (onClick event) and the main thread being idle and available to respond to that user-triggered event.

Cumulative Layout Shift (CLS) (measured using a score from 0 - 1)

This is very simply the amount of unexpected movements your webpage makes across its lifetime. Basically, how much your webpage jumps around.

If we take a look at this video[1], you can see that the there is a large advertisement banner that loads well after the page's initial load causing an unexpected shift of the content underneath it giving the user the impression that the page is unstable.

A few caveats:

CLS is calculated using an equation you can find here. This equation produces a number from 0 - 1, 0 being a perfect score and 1 means that your page is moving all over the place.
Click events that result in content moving do not result in layout shifts since there is a 0.5s grace period between the user click and the content moving during that time without making your CLS score worse as you can see here
CLS is calculated across the lifetime of the page, meaning that the length of time after which the content shifted does not matter, the only factor is that it shifted.
If the content shifts outside the viewport, it probably won't contribute towards your CLS score since the user didn't see it. Keep in mind that what's shown on the viewport is different for every user owing to the fact the user can scroll and move around the page which means that CLS can affect users differently.

We'll be looking more into each metric individually and the different optimization techniques we can use for each one in upcoming articles.

[1] all credit goes to https://web.dev/cls/ for the video.

React - Using Custom Hooks to Reuse Stateful Logic

Omar Moataz Attia — Sun, 02 Aug 2020 02:11:34 +0000

Today, we're gonna take a look at how we can share stateful logic between react functional components using a custom hook we're gonna call useHttp. This component will be responsible for the state logic related to calling APIs.

The problem

We have a component that makes a GET request

const ArticleDetailsPage = (props) => {
 const [article, setArticle] = useState(props.article);
 const [isLoading, setIsLoading] = useState(true);
 const { id } = useParams();

 useEffect(() => {
   const getData = async () => {
     const articleDetailsAPI = `/posts/${id}`;

     const response = await requester({
       method: "GET",
       url: articleDetailsAPI
     });

     setArticle(response.data);
     setIsLoading(false);
   };
   getData(id);
 }, []);

 if (!isLoading) return <PostDetails post={article} />;
 else return <FooterInfo content="Loading article..." />;
};

And another one that makes a POST request like so:

const publishArticle = async (values) => {
   let articleData = new FormData();
   try {
     articleData.set("content", values.content);
     articleData.set("title", values.title);
     articleData.set("description", values.description);
     articleData.set("thumbnail", values.thumbnail);
     const response = await requester({
       method: "POST",
       url: "/posts",
       data: articleData
     });
     const articleId = response.data.id;
     props.history.push(`/${articleId}`);
   } catch (e) {
     // do something.
   }
 };

Let’s take a look at the core difference between these 2 requests or components.

Right off the bat, one of them creates a GET request and the other one creates a POST request which means one of them needs to send data as part of the request body and one of them doesn’t. Other than that, they’re essentially the same, they both need to display some kind of loading state during request load time and then display some data based on the success or failure of that request i.e. they need to keep track of 3 things: loading, response, and error states.

Now, this logic is very common across every app that makes API calls. We don't want to rewrite it of every component that calls an API.

useHttp to the Rescue

We need a React component that keeps track of these things for us but that component is meant to be used as a hook i.e. it hooks into other functional components to give them extra functionality exactly like what useState and useEffect do. We can call that component whatever we want but since we want to make it obvious that it’s a hook, we’re gonna follow the same naming convention of useState and useEffect and call our component useHttp.

const useHttp = (props) => {
 const { url, method } = props;

 const [isLoading, setLoading] = useState(true);
 const [response, setResponse] = useState({});
 const [error, setError] = useState(null);

 return [response, error, isLoading];
}

Here’s the input and output of useHttp, we give it a url and a method (GET or POST) and we expect it to return the 3 things we talked about earlier: response, error, and loading states.

We’re going to add functionality to send content in the request body to support POST requests a little later but let’s get it working with GET requests first.

We wanna do something like this:

const getResponse = async () => {
     try {
       setLoading(true);
       const response = await requester({
         method,
         url
       });
       setResponse(response);
       setLoading(false);
     } catch(e) {
       setError(e);
       setLoading(false);
     }
   }

We don’t just wanna call this once we want to trigger rerenders based on changes to the 3 variables we’re tracking. We also want to reset everything if we change either the url or the http method we're using to make the request.

For this we can utilize the useEffect and useState hooks to handle both cases:

const useHttp = (props) => {
 const { url, method } = props;

 const [isLoading, setLoading] = useState(true);
 const [response, setResponse] = useState({});
 const [error, setError] = useState(null);

 useEffect(() => {
   const getResponse = async () => {
     try {
       setLoading(true);
       const response = await requester({
         method,
         url
       });
       setResponse(response);
       setLoading(false);
     } catch(e) {
       setError(e);
       setLoading(false);
     }
   }
   getResponse();
 }, [url, method]);

 return [response, error, isLoading];
}

What’s happening here is that we’re setting state to trigger rerenders of the components that are using the useHttp hook but we’re also tracking changes to the props which are method and url in this case.

Now, let’s handle the case where we need to pass in the request body content in case of a post request and use the useHttp hook with the POST request we showed earlier.

I haven’t gotten into how the requester works but it’s based on axios and it has the exact same interface so it already does accept data as an argument to be passed as content in the POST request body. All we need to do is allow the data to be passed to the useHttp hook like so:

const useHttp = (props) => {
 const { url, method, data } = props;

 const [isLoading, setLoading] = useState(true);
 const [response, setResponse] = useState({});
 const [error, setError] = useState(null);

 useEffect(() => {
   setLoading(true);
   const response = requester({
     method,
     url,
     data
   })
     .then(() => {
       setResponse(response);
       setLoading(false);
     })
     .catch((e) => {
       setError(e);
       setLoading(false);
     });
 }, [url, method, data]);

 return [response, error, isLoading];
};

Walking Right Into a Hook Violation

Perfect, right? Well, not really because if we think about the way we need to call our POST request, they’re based on an onClick event handlers and one of the limitations of React hooks is “Do not call in event handlers.” so this code clearly violates that.

// Definitely not an onClick event handler
 const publishArticle = async (values) => {
   let articleData = new FormData();

   articleData.set("content", values.content);
   articleData.set("title", values.title);
   articleData.set("description", values.description);
   articleData.set("thumbnail", values.thumbnail);
   const [response, error, isLoading] = useHttp({
     method: "POST",
     url: "/posts",
     data: articleData
   });
   const articleId = response.data.id;
   props.history.push(`/${articleId}`);
 };

Now we need to think of a possible solution to this problem. We need to call the hook on the root of the component not inside an event handler but we want to trigger the API call onClick.

A Not-so-smart Solution

What if we modify the interface of useHttp slightly and make it return a method that triggers the API call and have that method return the 3 states we wanted to handle? Let’s take a look!

const useHttp = (props) => {
 const { url, method, data } = props;

 const [isLoading, setLoading] = useState(true);
 const [response, setResponse] = useState({});
 const [error, setError] = useState(null);

 const triggerRequest = () => {
   return [response, error, isLoading];
 }

 return triggerRequest;
};

We want something like this, it allows us to call the useHttp hook without triggering the request, great!

The first thought I had about this was let’s send the data to something like a triggerRequest function inside the useHttp hook.

const useHttp = (props) => {
 const { url, method } = props;

 const [isLoading, setLoading] = useState(true);
 const [response, setResponse] = useState({});
 const [error, setError] = useState(null);

 const triggerRequest = async (data) => {
   setLoading(true);
   try {
     setLoading(true);
     const responseData = await requester({
       method,
       url,
       data
     });
     setResponse(responseData);
   } catch(e) {
     setError(e);
   } finally {
     setLoading(false);
   }

   return [response, error, isLoading];
};

 return triggerRequest;
};

This function manages the calling API part well and it does set the state but it doesn't manage the changes that happen after the API is called. By the time the API returns data, the code calling the useHttp hook will have already executed and it's no longer waiting to receive the response. We're close but we're not there yet.

A Better Solution - Back to useEffect

How can we leverage the power of useEffect to do the heavy-lifting for us? We can use it to work with get requests the beautiful way we showed earlier while also having the flexibility to pass data to it without violating hook rules we discussed earlier.

const useHttp = (props) => {
 const { url, method, data, isDelayedRequest } = props;

 const [isLoading, setLoading] = useState(false);
 const [response, setResponse] = useState(null);
 const [error, setError] = useState(null);

 useEffect(() => {
   if (data) {
     triggerRequest();
   }
 }, [data]);

 useEffect(() => {
   if (!isDelayedRequest) {
     triggerRequest();
   }
 }, []);

const triggerRequest = async () => {
   try {
     setLoading(true);
     const responseData = await requester({
       method,
       url,
       data
     });
     setResponse(responseData);
   } catch(e) {
     setError(e);
   } finally {
     setLoading(false);
   }
 };

 return [response, error, isLoading];
};

We added a flag called isDelayedRequest whose job is to tell the useHttp hook whether it should call the API immediately or later (like our POST request).

Now the code that triggers the POST request will look like this:

const [response, error, isLoading] = useHttp({
    method: "POST",
    url: "/posts",
    data: articleData,
    isDelayedRequest: true
  })

  useEffect(() => {
    if (response) {
      const articleId = response.data.id;
      props.history.push(`/${articleId}`);
    }
  }, [response]);

  const publishArticle = async (values) => {
    let articleFormData = new FormData();

    try {
      articleFormData.set("content", values.content);
      articleFormData.set("title", values.title);
      articleFormData.set("description", values.description);
      articleFormData.set("thumbnail", values.thumbnail);

      setArticleData(articleFormData); // triggers the request.
    } catch (e) {
      console.log(`Something went wrong while creating article! ${e}`);
    }
  };

the useEffect hook here is responsible for performing the action after the POST request succeeds since it's triggered when the response changes from the useHttp hook.

Alright, that's all folks! Let me know what you think in the comments and tell me how you use custom hooks to make your life easier. I'm always looking for inspiration.

You can check the code for this article here

This feature was written for creative outlet, a side project I created to share my thoughts with the world while learning about software.

Creative Outlet is open source, you can find the frontend repo
here or the backend repo here

Till next time,
Omar