There are many variations of passages of Lorem Ipsum available, but the majority have suffered alteration in some form, by injected humour, or randomised words which don't look even slightly believable. If you are going to use a passage of Lorem Ipsum, you need to be sure there isn't anything embarrassing hidden in the middle of text. All the Lorem Ipsum generators on the Internet tend to repeat predefined chunks as necessary, making this the first true generator on the Internet. It uses a dictionary of over 200 Latin words, combined with a handful of model sentence structures, to generate Lorem Ipsum which looks reasonable. The generated Lorem Ipsum is therefore always free from repetition, injected humour, or non-characteristic words etc.

Contrary to popular belief, Lorem Ipsum is not simply random text. It has roots in a piece of classical Latin literature from 45 BC, making it over 2000 years old. Richard McClintock, a Latin professor at Hampden-Sydney College in Virginia, looked up one of the more obscure Latin words, consectetur, from a Lorem Ipsum passage, and going through the cites of the word in classical literature, discovered the undoubtable source. Lorem Ipsum comes from sections 1.10.32 and 1.10.33 of "de Finibus Bonorum et Malorum" (The Extremes of Good and Evil) by Cicero, written in 45 BC. This book is a treatise on the theory of ethics, very popular during the Renaissance. The first line of Lorem Ipsum, "Lorem ipsum dolor sit amet..", comes from a line in section 1.10.32.

The standard chunk of Lorem Ipsum used since the 1500s is reproduced below for those interested. Sections 1.10.32 and 1.10.33 from "de Finibus Bonorum et Malorum" by Cicero are also reproduced in their exact original form, accompanied by English versions from the 1914 translation by H. Rackham.

A workshop tutoorials to teach you how to take photos

Workshop

Hello World

The React Docs are great and getting better, but I have always felt it lacked a basic explanation of how to fetch data. So much is devoted to state and props; we don’t get into where that state and props come from.

Some great libraries, like React-Query, help fetch data in a React app, but, unfortunately, we don’t at least have some basic concept of data fetching before we bring in a 3rd party library that we may or may not need.

For this reason, I thought I would quickly go over some basics regarding data fetching and some opinions that I like to follow.

There are two essential parts to data fetching: We need to trigger an action to get the data, and we need to store that data somewhere. This means we need to use useEffect and useState to handle those two-part. This is what that looks like:

In the above component, we have state that is updated when we get a user back from our API. That is the bare minimum we need when fetching data in a React app. Now chances are we want our Card to be a bit more dynamic, so lets, quickly update it to take any user:

With this update, we will get the user data of whichever userName is passed in. If the userName prop changes, we will fetch new data and set it to state when it returns.

This might not seem like much, but this is all you need to know to start fetching data in a React Component. However, I think it would be helpful to share my opinions on some of my personal best practices.

The “how” we get our data is not crucial to our React Component. All it cares about is that it requests the data and what to do when it comes back. There is also much more you need to do with the returned data than what my examples show. One typically gets more data back than you need. Also, sometimes the data you need requires multiple API calls. API’s also change, and maintaining that across your app can get complicated if each React component knows too much about how the data is fetched.

For this reason, I prefer to move the implementation of the fetching into its own function, typically in an api folder for organization purposes:

COPYfunction getUserData(userName){ return fetch(`/api/user/${userName}`) .then(res=> res.ok ? res.json() : Promise.reject(res)) .then(({fullName, images, bio})=>({ name:fullName, avatar:images.large, bio, })) }

Now our UserCard can be updated like this:

This is much easier to reason about in our Component and is more resilient if we change our back-end API.

Fetching data is not as simple as getting data and showing it. When you are fetching data, you are always in one of three states. You are either loading data, have the data, or there was an error fetching the data.

So it would be best if you handled all those states in your component, for example:

In our useEffect we start by initializing our loading and error states. We do this so that we will set our states back to their initial states and then fetch the data if the prop changes. On top of that, we added a catch and finally to our promise chain. If there is an error, we will catch that and set the error state. We use finally so that we will set the loading state to false no matter if we have an error.

There is also another state that we often forget about. This is what do we do if the component unmounts before our data gets back? We will have an error if we try to update any of our states after the component has unmounted. Also, what do we do if we change the prop multiple times and send off multiple requests? How do we know if we are updating the state with the correct user since we have no control over which data will return in which order? Luckily we can refactor our code to handle both of these circumstances.

In this refactoring, we are merging all three states into a single state object. This doesn’t just make things more convenient for us later on, but it also makes sense. Any time we are calling multiple setState functions, chances are we should be grouping those together. These states don’t work in isolation but are part of one state and should be updated together.

Next in our useEffect, we are initializing a shouldSet variable to true. Then we instead of setting the state in our .then or .catch we are returning a partial state with either the user or the error. In our final .then we then verify if the shouldSet variable is still true. If it is, we update the state with our partial state and set loading to false.

This makes this work because we are now returning a cleanup function that will change the value of shouldUpdate to false. This will be set to false if the component unmounts or if the userName changes and the effect is rerun. Either way, we won't update the wrong data or update at all if we don’t want to.

Once again, all this logic is starting to make our card cluttered. Also, the UserCard component doesn’t care how we get the states we do, only with what the states are. So it makes sense to refactor this out into a custom hook:

We have moved all that logic state into a single hook that takes a userName and returns a the fetchState. Now we can use that in our component like this:

Now the UserCard is easier to reason about again, and we can compartmentalize how we fetch that data and what to do while we fetched our data. It’s important to point out that this hook doesn’t need to be in another file and or made “reusable” at this point. As you go, if you find a common pattern that solves a problem, then go ahead and abstract it generally.

These are the basics of how to do data fetching in React and some good strategies to solve common problems associated with it. Hopefully, this helps fill the gap in your React apps.

A detailed explanation of data fetching in React

I am MANAN and this is my blogQuote of the Day: Memento Mori

Hello World

I am MANAN and this is my blog
Quote of the Day: Memento Mori