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 โฎ๏ธ
I made a slight typo (it should say AJA,), but if I change the article itโll throw off the hash which seems irrecoverable once git(Hub) migrates the history of the file forward. Noted! Just ignore ๐ช๐ฌ