The Debug Life at AnyPerk
Being able to debug code quickly and decisively is a crucial skill for every programmer. Here at AnyPerk, we’ve started to document some of the interesting code debugging cases we’ve come across.
Case 1: The Giving Form
At AnyPerk, we enjoy recognizing and giving rewards to each other. Unfortunately, the form we use to send such events was not transitioning correctly after submission. This resulted in hiding any sort of form submission feedback from the user. Thus, the recognition senders, unaware that their requests had been successful, submitted the form multiple times.
Frontend or Backend issue?
It’s important to find out which part(s) of the code base the error occurs in. In most cases, the first question we ask is whether the error is caused by the Frontend and/or the Backend.
To figure this out, I usually use the Network section of my Chrome Developer Tools.
Since I know this form submission is a XHR request, I’m going to filter the requests to only have XHR requests.
Finally, before I submit the form, I want to clear the network history so I can clearly see what new requests happen after I submit the form.
Now, after I submit my form, I can clearly see what happened with the new form submission request.
The ‘give’ request seems to have succeeded with the expected 201 status. It doesn’t seem like a Backend issue to me.
Debugging the Frontend
Another Chrome debugging tool I use quite frequently is the JavaScript console.
When I go there, I see this:
Because we only uglify in the Production environment and I’m debugging on a QA environment, I can simply click on the link on the right side of the console error to take me to the buggy code.
Unfortunately, we are using a build process that translates our written es6 JavaScript code into a somewhat obscure single file of es5 JavaScript. This can sometimes make discovering the source of the error difficult. In fact, the code you see above is actually 3rd party vendor code. As a developer, I would have never seen this piece of code while working on the code base. So where do we go from here?
Debugging webpack’s build
If we scroll up, we can see the webpack’s comment next to the module’s declaration.
Now, if we search ‘1241’, we should be able to see the name of the module.
Finding the module
Now that we know what module the error is occurring in, we can search in our code base to see where this module is being used.
Luckily for me, the module is only imported in one location, and is only used on one line.
Let’s fix the issue
After reading the error and looking at the related line of code, it now seems rather obvious what the bug is.
It looks like setHeaderNav
, which is being used as a React.js ref callback, is sometimes being called with a null
c
parameter, causing the Cannot read property '__resizeListeners__' of null
error. Thus, changing elementResizeEvent(c, this.setHeaderNavWidth)
to c && elementResizeEvent(c, this.setHeaderNavWidth)
will fix the issue.
Case closed
For more on employee happiness, please visit: https://anyperk.com/.
To join our team, please visit: https://jobs.lever.co/anyperk.
More on me: https://www.linkedin.com/in/yiziz.