Preparing for the fix
To ensure I can get updates from the original bridge-troll repo, I’ve setup the upstream remote for the repository by using the following command:
git remote add upstream https://github.com/humphd/bridge-troll.git
Trying out the app before working on it
One important thing is to ensure the app works as is and learning how it works before attempting to make changes to the app. I did a quick build to see how the app works. According to its README.md, I should be able to run debug to bypass GPS based location only, allowing me to navigate the game through double clicking the mouse.
npm run debug
However, I soon found out that the debug mode was not working. I began examining the code files, making educated guesses based on the name of the files to see where I could save the problem. I came across a file named geo.js. In this file, there was a line that enabled the debug mode. It appears the parcel.js module was having issues with parsing flags.
I bypassed the check by commenting out the if statement, enabling navigation using double mouse clicks.
The next step is to figure out where the code affecting the maps lived. Luckily, the naming convention for this project was easy to understand. Navigating to maps.js revealed the code used to generate the map.
Choosing the proper theme and icons
After browsing through the series of themes, I have settled on the World Street Map theme for dark mode. The choice was chosen due to its red and yellowish tint, which reduces the amount of blue light coming from the screen at night, making the app more usable without reducing the visibility of the streets and their names.
As for the icons, the default sets were kept because they were suitable for the purpose of identifying bridges that have already been visited versus bridge that have not yet been visited. Since the roads were in a pale red color, the black locks that came default was a good choice to create contrast on the screen.
Determining sunrise and sunset
To determine the time for sunrise and sunset, I used an node module called SunCalc to detect positions of the sun relative to the time of the user’s location. This information is used to calculate the time for the end of sunrise and when sunset begins to allow automatic switching between dark and light mode.
Exporting the code to a separate module
Once our initial implementation works, our goal now is to separate the code written into its separate module for re-usability.
Creating the module and factoring out dark mode code
I began by creating a separate js file for our new module. I called the module ‘displaymode’.
At the beginning, I had trouble figuring out what parts of the code inside map.js’ init() method that could be factored out for the dark mode feature. After consulting Professor Humphrey, I realized that the new module can have its own init() method, have logic that will figure out the time of day based on given latitude and longitude arguments and expose a
getMode() method to allow map.js to obtain the proper theme to render.
Exposing a setter method in DisplayMode module
In order to facilitate re-usability in other parts of the app for the future, I’ve included a setter method
setMode() in the DisplayMode module, which allows the user to pass the string ‘dark’ or ‘light’ to manually set the theme of the UI.
Preparing to ship new code
Once all the code has been written, I proceeded to run
npm run eslint
The results show 2 warnings and 1 error. I realized when I moved the code over from map.js into displaymode.js, I had forgotten to remove the variable that requires SunCalc node module.
I then proceeded to investigate the warnings regarding console statements in csv2json.js. However, my finding is that those 2 lines of code are related to error handling and printing results to the console. Therefore, while it is not recommended practice as outlined here, I left it alone.
The next thing I did was run
npm run prettier. The purpose is to ensure the format for which my code was written conforms to the bridge-troll repository.
Creating the commit
Once linting and prettying were performed, I added all of the files using
git add command and performed a
git commit to upload my commit.
Pulling the latest changes
To ensure my code base is normalized against upstream, I quickly performed
git pull upstream master command. I then got warnings regarding conflicts with merging with package-lock.json.
It appears that the original repository had been updated to use WebPack instead of parcel.js.
To resolve this issue, I forcefully removed package-lock.js using
rm -rf package-lock.json. Then I proceeded to execute
npm i to allow package-lock.json to regenerate itself; In addition, install WebPack
I then executed
npm run debug to test the application to see if the new added code is working with the latest files pulled from upstream repository. Indeed the application loads.
To ensure night mode works, I purposefully reversed the if statement in displaymode.js to ensure the dark mode theme appears as expected.
Commit and Push the changes
Now that everything is working, I added the files and create new commit and detailed the changes I’ve made for implementing dark mode. The commit was then pushed to my own forked repository.
Creating pull request
Heading over to my own bridge-troll repository on Github, I now see a sign that says “create pull request”. I was presented with a form to fill in once I clicked the create pull request button.
I provided details regarding the issue number that I was working on and the details of the things I’ve added in the pull request.
One thing I forgot to do after pushing all of my commits was that I had been creating commits against my forked version’s master branch. This is very bad practice and something that I will remember to never do in the future.
I realized this when I was unable to see the create pull request link on my bridge-troll repository. To work around this issue, I created a separate branch using
git checkout -b issue-6. The name issue-6 is a simple, yet descriptive name for the problem I was addressing.
Overall, I found this exercise to be very fun and practical way of learning the process of fixing a bug and creating a pull request. While I recall all the steps mentioned during the lesson, it was obvious that I did not recall this during the actual fix. With this exercise, I now know which areas I should pay more attention to for my future fixes.