I am currently in a coding boot camp and we just got to React. Learning about the power of State has been mind-blowing. So mind-blowing that while I was completing the labs for the curriculum, I tended to create State everywhere.
"You get a State and you get a State and..."
I completed the assignments and got greens on the "npm test', but my instructor was not happy with my approach. It was a bit confusing.
Until the "aha" moment.
I was implementing bad practices because I was thinking too small. The memory allocation process for assigning and managing State in a small project for a boot camp curriculum: minuscule.
The problem is that most companies I dream of working at have millions, if not billions, of users. And they move billions, if not trillions of bits of data every day. So each user engaging in a process that re-renders components a few dozen times vs. 2 or 3, times all the data that has to be manipulated and shuffled around, times the numerous memory re-assignments is crazy math. The cost of memory allocation on a process of that scale is enormous.
So the biggest benefit of assigning as little State as possible is that it makes your work more appealing to the companies you want to sell it to. Lower memory costs mean a faster product and more profits.
Instead of creating State every time you feel like you need it, get creative with the State you have. Most often you will not be able to manipulate the data on the api you are connecting to, nor should you. But when you do a GET request to get your own set of data from the api, that is when the magic happens. Whatever you need to make your project shine with the data from the GET can be implemented at that point before you assign it to State.
You can filter it, you can slice it, you can store it into an array of objects and add properties to each of those objects that store values that you need for your project. As you work on your project more and more, you will realize that you may have missed some values that you need. No sweat, just modify the initial function that preps your data for State. You can update that function, or make helper functions as much as you need to prep your data exactly the way it is needed for your project.
Take this code I adapted from a recent project. Here is an example of one of the objects in the array in the database:
Next is a useEffect that fetches data to be stored in State when the component loads:
If you look closely at line 13, you can see that I have a boolean State that will provide a value for a sort function later on in the project. But the data received does not have an age property. Now I have 2 options. Create an age State and store some values in there, or I can manipulate the data before I initially set it to State:
Once the fetch returned a valid json object, I passed it to the helper function to add an age property to each object in the array. Then I returned the array of updated info to be passed into the function used to set the State of the explorers. I can either do more manipulation in the existing helper function, or if too much updating is needed, I can create as many helper functions as I need to before I set State.
And yes, I could most likely do some refactoring and get rid of at least one of those States you saw in the image. But it was a timed exam and I did not want to get fancy.
Take a moment before each project and try to get an idea of how you want it to look, then structure your data accordingly. Repeat as needed. Your users will thank you.