When we work in a company or a project, we do not work on feature development. Sometimes we spend most of our time fixing bugs. Sometimes this takes even more time than feature development. Here, we can solve the problem somehow, that is not a problem. The important point is where exactly we look for the error. If we are not looking for this error in the right place, then we can waste a lot of time. I would like to share a few points that I have observed so far as I have experienced. The main points I will focus on in this article series will be as follows. I will publish a separate article for each item. Here are these titles;
Where could the folder/file that could cause the application be?
Could the problem be due to the package used? (Soon)
Did the error occur later? Is this a regression? (Soon)
The reason I am sharing the article as a series is that I want to keep each article short and detail it as I want. In this way, I think the benefit of research and testing will be more.
Where is the application causing it?
The first place I see the error while developing an application is either the browser or the editor. If it is the editor, you are usually making a mistake in the relevant code section. It will be enough to look at the relevant variable or function to easily solve this. Our focus will be on the browser side. Let's go into a little more detail here.
First of all, what exactly is the error? Let's draw a scenario. Let's imagine that we have a system like this. We are developing an Instagram-style social media application. Here, users can share photos, send private messages, create and edit their profiles. Let's think that we use packages such as redux and redux saga as state management. Let's assume that it covers simple features. If we summarize the steps of the logic in the application as follows;
The design that will appear on the screen is created with the Component.
When sharing a photo/sending a message/editing a profile, the communication between the action we perform in the Component and the Redux action is established.
After the message arrives at the Redux action, the necessary operations are performed first with Saga and then with the Reducer.
The updated data is transmitted to the Component by editing the state from the Reducer.
The data in the Component is updated.
If I don't see the data correctly on the screen after the API query we made
In such cases, the first thing to look at is to open the Network tab and examine the API request we sent. Here we need to check that the incoming and outgoing data is correct. If we have processed them correctly, then everything up to this point is working correctly.
At this point, the point we are stuck at is most likely in step 4. Here we need to do a detailed research. First of all, it is necessary to examine the relationship between saga and reducer and to pay attention to whether the data comes and is processed as desired. Sometimes we try to examine this by adding a log in the code section, but this sometimes takes too long. The easiest method here is to install the Redux DevTools extension on Google Chrome and look at the data we send to the actions. In this way, it may be easier to find where to look. After that, we can solve the problem after making the necessary edits in the code section.
If the API query is correct, the reducer is updated correctly but I can't see it on the Web
Here is the 5th section that needs to be paid attention to. This means that everything is updated correctly but we are having problems in the lifecycle section or rendering the component to update it. Here, it is useful to examine the Component in detail and pay attention to why the data is not updated. It is useful to examine useEffect and props. Are we sending it correctly? Have we set the conditions in the rendering section correctly?
I wrote my message and I am sending it but I am getting an error or I cannot send it correctly
This is where we need to spend a little more time to solve the problem. Because here, both the Component and Redux Saga files come into play. If there is too much logic and code between these two sides, our job becomes even more difficult. We can find this by being a little patient and putting the logs in the right place.
The reason I wrote this article was actually to write about the mistakes my colleagues made regarding how to research and produce solutions to the problems they encountered. I actively implement these and can take action quickly to solve problems. That's why I wanted to share this.
Respect!