For those of you unfamiliar with Dame Julie Andrews iconic performance, she once sang:Let’s start at the very beginning, a very good place to start.
I know this can sound tedious, but I promise it’s the most focused way to address the problem.
As the programs you work on begin to grow in size, it is going to be significantly harder to jump around to where you think the issue might be occurring.
For someone who is willing to admit he’s not perfect and very far from it, I have found that starting from the beginning and walking myself through what’s happening is the easiest way to get going and find my solution quickest.
Debugging in Action:I think the perfect example to work with would be to address an external API request that we’re ultimately going to send to our Redux store.
The issue is that I want to find all the local pizza shops in my area.
To do that, I input my ZIP code and click Find Pizza.
Unfortunately, when I do this, nothing is getting sent to my store and my app is breaking.
Now, I’m frustrated.
But, I know what my problem is and what I need to fix.
Before I even begin to start looking at my code, I want to just talk out the procedure of what is supposed to be happening in my app.
The procedure is:I input my ZIP code.
I submit said ZIP code and send a request to the Pizza API.
The API returns a response.
I convert that response into JSON and then filter through all the pizza shops to get what is in my area.
I store those pizza shops.
After writing all this out, I have come to realize that there are at least five different places where something could be going wrong.
Yikes!.That’s more than I realized.
But, now I have a general idea of where to look, and I have an idea of where to start.
Time to get debugging!My first place to examine is my form where I input my ZIP.
I move on over to the component where I find that form.
Then I think about what I need to do.
I need whatever I type to be saved in the internal state and I need that internal state to trigger an API request on submitting this form.
Great!.So I need these snippets of code:<form onSubmit={(e) => this.
handleSubmit(e)}>&<input onChange={e => this.
handleChange(e)} />&handleChange = e => { this.
setState({ zip: e.
target.
value})}I check to see if I have all of this code, and I do!.Great, now I know that I am getting the proper ZIP and submitting my form when I hit enter.
I am now set to move onto my next step.
My next step is to submit the ZIP and make an API request.
The process in making that happen is to trigger a function from my Redux actions that makes the type of API request that I need.
This action also takes in the Zip found in my internal state to make sure I can filter the response.
So I need to make sure that I have the following code in this component:import {getPizzas} from ".
/store/actions/pizzaActions"&handleSubmit = e => { e.
preventDefault() this.
props.
fetchPizzas(this.
state.
zip)}&const mapDispatchToProps = dispatch => { return { fetchPizzas:(zip) => dispatch(getPizzas(zip)) }}&export default connect(mapStateToProps, mapDispatchToProps)(PizzaPage)Four places to raise an error, four places to check.
The first place I want to check is in my imports up top.
Did I remember to import this action?.I did.
Okay, now I’m going to move on to the bottom of my and check if I remembered to connect this component.
When I take a look at the bottom, I find myself connected to my Redux store and actions.
Wonderful.
Onward and upward we go.
Now I want to look at my mapDispatchToProps.
I do so and something doesn’t seem right.
I see:const mapDispatchToProps = dispatch => { return { pizzaFetch:(zip) => dispatch(getPizzas(zip)) }}Does that match up top?.Let’s check.
Further up, I see:this.
props.
fetchPizzas(this.
state.
zip)Now I have found my problem.
I’m calling a function that doesn’t actually exist.
Okay!.Some quick tweaking to my mapDispatchToProps and voila, everything is working how I want it to.
I did it!.I have debugged.
I am a master exterminator!Alternative Solution:Now I know you might be thinking, “It seemed like an awful long way to get there when the problem was so simple.
” In this particular example, you’re absolutely right.
The quickest way to have solved this problem would have been to have our Chrome console open, provided you are working in Google Chrome.
For those of you unfamiliar with the console, it looks like this:It can be opened on a Mac by either holding ctrl and clicking on the page, then clicking inspect, then clicking on console, or simply by pressing alt+cmd+j.
On a PC, you can open it by right clicking on the page and following the same steps or pressing ctrl+shift+j.
If we had this open when we submitted our form, it would have logged an error much like the one above and told us that this.
props.
fetchPizzas() was undefined.
We could have easily worked from there.
More often than not this is a fine enough approach.
Something doesn’t work, we see what’s going on in our terminal, and work from there.
So why did I have us go through this whole drawn out process?.Because what you see in the terminal is not an exact science and doesn’t always return the most exact information, especially when dealing with React.
The logged error might not be happening where you or the terminal think it’s happening and it can lead to getting stuck.
You know your code is right.
You’ve checked documentation and other tutorials and your code matches what it’s supposed to match where the error is logged.
What are you supposed to do?That’s why you map out the journey of that particular action.
When you have guide posts as to where each step in the action takes place, you know everywhere that this hidden bug can exist.
You also know the order in which to check.
From there on out, the rest is going from point a to point z in order.
A Final Note on Procedural Writing:To anyone who has been reading both my articles on algorithms and my artistic background, you may find the contents of both to be somewhat contradicting.
I understand and agree with that.
But, I’d like to raise a counter-point.
In my experience, the best way to approach all writing is to approach it abstractly, followed by a procedure.
In reference to debugging, the abstract aspect is when you evaluate the differences in how you’ve written this type of action before and how it might need to exist in a varied way for this particular instance.
That way you can evaluate all points of view and come up with best solution.
The procedural aspect comes in once you have examined all points of view and come up with what you believe to be the best solution.
Now that you have an endpoint, you can map out your own path to get there.
With this map, you may even find other aspects of your code you can improve for the best possible application.
Finally, as always, I’m not here to dictate how you should be writing, because my way may not work best for you.
However, I do hope you consider addressing all aspects of your code abstractly and procedurally.
It helps to maintain focus, it helps to keep everything organized, and most importantly, it helps to remove all future bugs quickly and efficiently.
With every bug we remove, we bring ourselves closer to moments of happy dances.
.. More details