In the Frontend, there is something called State that represents the state of the components in the app. Simply put, when you send a message to Crush, that message will have the statuses of sent, received and viewed (also viewed without replying is a status that you recognize yourself, not a message). State will be explained below). The above states are the value of the state in the app, which is displayed for the user to see. However, there are also states that are born to handle the background in the app without showing the UI. For example, when you surf the Facebook Newsfeed, the content will actually be paginated, each time you swipe up the app will load the content of the next page to display and the current page number is an implicit State.
You can also read more articles here: https://pixta.vn/state-management-la-gi-can-luu-y-gi-khi-su-dung-state-management
What is State Management?
An app will have a lot of states, sometimes they work independently, or depend on and are bound to each other, so we have to manage it. That is State Management.
2 points to note when working with State
State Management has never been a simple thing, knowing how to use State is easy, but optimizing it is difficult. After working with State for a while, here are 2 things I have learned:
State should not be abused
First of all, not all component states in an app are necessarily handled by State.
Back to the prologue, the message states are sent, received, and viewed, which will be determined by the value from the APIResponse. What about viewed status without reply? Should I also use State to handle it?
In our opinion it is not advisable. Since this is a dependent state, it can compute from another state, specifically: If the message you sent has a State of viewed and the latest message is still yours, it can be inferred that the message has been received. watch without reply. Of course, this status is not shown directly on the app like Messenger. Or in the case of messaging, each message will have 3 states as mentioned and on the app there will be an icon (circle) next to the message to represent:
- Sent: circle with white tick
- Received: circle with blue check
- Read: the circle contains the avatar of the person who read it. So, does the information that the circle icon contains need to use state to handle? There were times when we thought we would code like this:
But I’ve realized: The content of the circular icon depends on the state of the message, so it doesn’t need to use a new State to handle. In essence, we can handle the following:
Just a simple change but it also helps us optimize our code better when working with state.
Be careful with setState
What is the problem here? That setState is an asynchronous function. So the following code will not work properly:
Now, right after calling the setStatus function, we all expect that the state status will be updated immediately. But no, setting a new value for state status will be injected into the event loop and processed later.
Looking at the example above, it can be seen that instead of using callbackToParent(status) , we use callbackToParent(res.data) and that’s it, right? But in reality there are more complicated cases than that!
When I implemented the Upload function, I had a complicated problem to handle the status of the uploaded files. I have 3 files to upload at the same time and every time the upload is done (success or failure), I will update the status of these files and the code I process after uploading as below:
I was hoping that the above code would handle it properly, but it’s been a nightmare when it returns me results like this:
I was really confused while debugging this part, as far as I understand, the problem is because my state files are getting stale value. At the time file 1 is finished, file 2 and file 3 are still uploading, looks like there is no problem, but then when file 2 is finished, at this scope, the files state inside the handleFinishedUpload function still contains the value including file 1 and file 3 uploading, even though previously updated files state with file 1 with status as uploaded.
So what to do? Fortunately, setState allows us to pass in a function instead of an object. This function contains 2 arguments including the first argument is previous state and the second argument is props at the time of update. And with the above problem, I was able to fix it by fixing it like this:
Finally, everything looks more “handsome”!
Above are 2 problems I encountered when handling state for React App and how I handled them. Looking forward to receiving everyone’s suggestions and experiences when working with Frontend.
Thanks for reading. Have a nice day!