When I debug front end issues or need to apply styling/markup/content based changes for front end UI code (we’ll stick to React.js based apps for the purposes of this article), I identify a static piece of text that is the same (constant) each time the particular route (most all front end frameworks have routing functionality included) in question is visited (e.g. a piece of text that it is not the result of a JSX expression). Once I identify that piece of text, I feed it into git from the command line prompt. For example, say the homepage has a bug. It also has a heading that reads:
To quickly determine which source files contain the bug for our ensuing patch (assuming the bug report is correct and it’s not a “user error”), I could:
- use the cd command to navigate to the root directory that houses all the React.js related files (typically App.js would be locates here as well as other sub folders) an
- git grep
“Diversity, Inclusion, and Equality” - a). use the list of files output to the terminal to narrow down my search, b). use the component exported for that UI route (there can at most be one file as a component is just a function exported from s file that is fed to react-router and passed in as a prop
- Debug the component from step 3
Doesn’t Integrating sentry.io or A Error Logging Tool in my Application Make this Heuristic Redundant?
If I’m using sentry.io, I’d have a stack trace and the actions (clicks, form inputs, etc.) the user took up to encountering the bug, as well as the HTTP/AJAX request and response which makes this heuristic less ideal. However, there are times when exceptions are not handled properly (no log would be propagated), or an application may not have a third party integration hooked up for error logging (at this point you have the url only at your disposal and potentially a screenshot if they world around you is feeling gratuitous at the time). Nonetheless, even with a logging tool like sentry integrated, why not use both approaches accordingly? The less you have to rely on clicking around and scanning with your eyes, the better! It’s efficiency and ergonomics that count. Every keystroke is additional “work” that must be done by you as a developer. Your ability to “limit” the work you do to have to solve a given problem is what matters most. The approach I’ve outlined here also expands to studying and learning source code on the fly. You’ll typically spend your first week or so at a new job learning a new codebase and business application. At any given point in time, you may be curious about where the source files that render some portion of the app are located at. It’s another tool (who doesn’t love Swiss Army knives) to aid with studying, discovery, and source file isolation and it’s very lightweight to implement with a natural and organic flow (it’s time consuming to map the route in the address bar to a substring inside the Route.js file as I’m working. It’s a visual translation tax with a higher degree of cognitive overhead). It’s also much faster than using the GitHub web interface to “full text search the indexed source files”.
When you can trivially use a third party integration or library to complete a task, go for it. Otherwise, the more you can leverage the terminal/system shell to get your work done, the better! Happy programming my friends, it’s efficiency that counts! ❤️
Curiosity killed the cat, but it turned all the greatest scientists and engineers into determined men and women who wanted to divide and conquer without much hassle - Antwan R. Wimberly
and last but not least....World Peace ☮️
https://www.centerforhealthjournalism.org/2017/11/08/how-racism-and-microaggressions-lead-worse-health - #️⃣Afrℹ️c@ 📻 🦶🏽 🌍 🗺 ☘️ 🇩🇪