Have you ever had a conversation that went something like this?
Support Rep: “I just heard from a prospective customer that they’ve been trying to add an item to their cart, but the button isn’t working.”
You: “Okay, let me verify.”
A few minutes later, you can confirm that the button the prospect was trying to click is indeed not working.
You: “Hey Developers, there’s an issue on our site. I need it to be fixed ASAP so we don’t lose any more sales.”
Dev Team Manager: “Okay cool. What’s the issue?”
I would always feel awful asking my developers for a resolution, without being able to provide them with any useful context or indication of where to start their efforts.
This evolution is great for internet consumers and users, but it’s not so great for the programmers in charge of your front-end functionality. Because unfortunately, as with anything that increases in complexity, so increases its vulnerability to errors.
1. DOM-related errors
2. Syntax-based errors
3. Undefined / Null variable usage error
4. Undefined method error
5. Improper usage of the Return statement
As you can imagine with the above spread of error categories, what actually happens when a bug occurs will vary.
The quick fix next time a DOM error gets thrown? Ask your dev team to make sure all referenced elements are added into the first few lines of code.
What’s particularly nice about knowing this? Instead of asking your dev team to spend an hour recreating the error to pinpoint what went wrong and where, you can provide them with direction with the root cause so it only takes a few minutes to quickly reorder the code.
Example: Your programmer may need to use conditional statements to address multiple conditions. If there is a required parentheses that is missing to properly identify these conditions, a syntax flaw will be detected and reported.
Imagine you were working on a new page and, during the HTML coding process, you forgot to close out your Href tag. Suddenly, you don’t have a phrase that is hyperlinked… You have the rest of your blog hyperlinked. A syntax-based error is sort of similar to that, but almost always significantly less obvious in production.
Another example of a syntax-based error occurs when the programmer has forgotten to properly pass on their coded argument to a function.
With any language the more you’re immersed in it, the more fluent you’ll be. So for developers, practice really makes perfect on this one.
Improper Usage of undefined / null Keywords Explained
“Undefined” indicates that a variable or other related element lacks an assigned value, where one is usually expected.
Put into a real-world example. Having a “null” value is like having a display case with nothing in it. An “undefined” is as if the display case itself is missing.
In a typical stack trace, an incorrect usage of null / undefined may look something like the following:
As with the other explanations, even this basic level of understanding will help you direct your development team to where their efforts should be focused.
Improper Usage of the Return Statement Explained
A Return statement stops the running of a function so its value can be outputted; it tells a given function when to return with a value. When used incorrectly, inputting a return statement will interfere with application performance.
There are a few ways to “break out of” a function loop to move onto the next element in your code. Programmers can use Break to exit from the loop, and Return to go back to the step where the function was called or to stop further execution and output a value.
In fact, I can almost guarantee that if your error handling is dealt with through customers reporting into your support team, you’re missing up to 90% of real onsite errors. Yes, only 10% of customers will ever get frustrated enough to create a support ticket. Oftentimes, they just leave your site; a potential sale is completely lost.
Now obviously it’s neither effective nor efficient to have someone on retainer 24/7 to constantly check site functionality for all entrance avenues, devices, browsers, physical locations, buyer journeys, etc. And other application monitoring tools don’t provide the extra data developers need to actually solve an identified problem.
There is a solution though.