Recycling techniques to help bust another bug ♻️
For this release, I knew that I still wanted to stay within the realm of AMO but instead of working on the back-end, I decided to challenge myself with something new in React for the front-end! Although I am extremely new to React, the responsiveness by Matthew R MacPherson (@tofumatt) and Kumar McMillan (@kumar303) on the issue itself showed promising signs that the project is alive and there are individuals who are committed to helping new contributors like myself find success. Why not check out a few GFB’s (Good First Bugs) for yourself?
AMO has two requirements you must meet in order to be able to build the project:
- Have Node v6.x LTS (Long-Term Support) installed. We highly suggest using nvm (Node Version Manager) to install version 6 amongst other versions like how I have done for myself:
- Have Yarn installed which will manage all of the dependencies and allows you to execute commands like
yarn eslintto check for linting errors:
And.. that’s it! Wowza — just two requirements and you’re good to go 🙌🏽
Understanding the Bug
Current Behaviour: As of right now, we’re showing query results that aren’t really relevant for 1 or 2 character long search terms.
Ideal Behaviour: To prevent unnecessary API requests to the server and to improve overall performance, queries should only be conducted when the user enters 3 or more characters.
Working Towards a Fix
For most issues, the first few posts contain “breadcrumbs” — keywords, phrases and sometimes even files that help contributors get off on the right foot. For me, I usually opt to use the dev tools and search for unique CSS classes that I can later then use to search the entire codebase in VSCode:
After finding the phrase “AutoSearchInput”, I decided to give that a shot and opened VSCode then searched for the same phrase using
F on MacOS — the results looked promising!! See for yourself:
I knew that
src/amo/components/AutoSearchInput.js was probably the right spot but I needed to look for something that initiated the API requests. About half-way down the page, after skimming through constants and imports, I noticed a function named
handleSuggestionsFetchRequest() had a very interesting constant —
And so realizing that this piece of code checked if the user entered a value GREATER than the allowed length was a great starting point. For my patch, I would have to mimic the same logic but check if the user entered a value below the threshold of 3 characters.
After throwing in a new constant,
SEARCH_TERM_MIN_LENGTH and adding a new check to see if the user’s search term was valid, the update looked like so:
And reflected as such in the UI:
Tying Up Loose Ends
Adding code calls for adding new tests — something which school doesn’t do enough! Piggybacking off the existing tests allowed me to observe, modify and reuse existing code, but slightly change to simulate a search term that was too short:
After a back and forth discussion with Kumar about refining my tests, I was met with a beautiful purple “Merged” icon and patch #16 in my OSS career! I’m hoping to hit a solid 20 before the beginning of summer and celebrate with some new stickers. If any of my friends from Mozilla are reading, I’d be happy to reimburse for shipping 😸🙏🏽
Until next time,