Bridge-Troll project: Implement dark mode

This week, I was tasked to implement dark mode for the bridge-troll project.

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

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, 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

This application uses a node module called Leaflet JS. It is an open source JavaScript library for creating mobile friendly maps. This library contains a series of themes also known as leaflet providers.

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

Screen Shot 2018-03-18 at 3.52.03 PM.png

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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s