TurtlesTab Chrome Extension — a Chingu Voyage-2 project
Background:
Chingu is an online community that organizes participants into remote teams that build a real-world web app or site within 5–6 weeks. My team of 4 (Eun Park, thorbw , and milesj76) were inspired by the InfinityTab Chrome Extension and decided to create an alternate version with changes that we thought were needed.
Link to TurtlesTab Chrome Extension
Workflow:
- git for our version control. I found it helpful to have many small commits, which made it easier to review the team’s code and revert changes if needed, and the git workflow is well-suited for that since repositories are cloned locally. Every member had their own individual branch from which they would push stable commits into the main development branch.
- I used Sketch to create the UI mockup, and exported it into Zeplin as a sharing platform for the rest of the team. Zeplin is pretty cool in its ability to parse relative code from each individual element, as well as create a color-palette and font-book from my imported layouts.
- Almost-daily status updates in Slack where members describe what they have been working on and whether they need any help. These are usually a sentence or two long.
- 30 minute to an hour-long weekly team meetings in Slack and group voice calls in which we discuss the overall progress of the project and whether we will finish our goals by the deadline.
- Trello Board to keep track of each members tasks with a backlog section from which tasks can be chosen from.
- We all used different text editors, but I personally really enjoyed using VSCode. It had nice git integration and was really easy to push/pull/merge conflicts with the click of a button. One exception — pull requests were easiest through the github site.
- Create-React-App framework. I really loved this framework. It was easy to read their guide and integrate numerous things such as eslint, bootstrap, sass, jest testing suite, and export into Github pages.
Process:
Since our team only had experience with CSS, HTML, and JavaScript, we decided this project would be a great chance to learn how to implement JavaScript-based UI with the React framework. After a bit of research, we decided to use the create-react-app project template to bootstrap our application, and I highly recommend it for those using React. Using React lets you prototype in a webpage before making the final application, which is much faster since you can use common web development tools and test locally.
The project was split into 2 phases: MVP and Chrome Extension.
Phase 1: Achieving the MVP
As we had no idea how easy or hard React was going to be, we set the MVP to be a webpage with the completed layout, the Google search bar and clock, and the Notes and Todos tabs. Each team member took a feature, and were responsible for its completion.
- Since React has a unidirectional data-flow from parent to child components, there was an attempt to use Redux to share state information between components. This ended up being a poor decision in hindsight because while React is the perfect framework to learn after JavaScript (since at its core, it is still using pure JavaScript to implement its functionality), Redux has abstracted so much of its functionality that there was a disconnect between the code you needed to write and the functionality it achieved (e.g. mapStateToProps() works almost like magic and it is not immediately obvious how and when Redux will call it).
- The most common React bug/error that we kept running into was issues with the parent/children relationship of components and the flow of data from state to render.
Once we completed our MVP with 2.5 weeks to spare, we decided to go after our reach goal of creating the complete Chrome extension.
Phase 2: Conversion to a Chrome Extension
In this phase, we had to convert our webpage into a Chrome extension and add the additional tab features of weather and browser functionality (bookmarks, history, and apps/extension).
- The first struggle was converting the project into an actual Chrome extension. After some trial-and-error, we determined that the only change needed was to modify the manifest.json according to the Chrome extension guide. This was pretty much the only thing we needed to do to convert it - very easy!
- Once it was an extension, there were constant errors when calling the Chrome APIs. Initially, we thought we had to do some sort of message passing between the JavaScript and Chrome, but nope, we just had to disable eslint in the lines where we call Chrome APIs because eslint does not natively support the Chrome API and was causing builds to fail when it threw up errors about unrecognized functions and variables. This took days to figure this out, so please learn from our mistake!
- Our workflow changed — instead of seeing changes on file-save in a local server, we had to run
npm run buildto make the build folder and upload it as a developer chrome extension to see changes. This greatly slowed down development so it was good that we had already built and tested most of the functionality as a webpage.
Lessons Learned:
- At the very least, a few days before the deadline, I recommend having each team member go through every feature and list out all the bugs and weird UI kinks, and then fix them! I totally forgot about this and had to press my team in the last two days to work out all the small bugs we ignored. Ideally, you will test and QA your application as each component is brought online.
- Stress the need for clean code. The team will need to read through each other’s code to look for bugs so make sure it is easy to read and add inline comments as needed. We did not do this, but a good practice would be to establish a simple coding style at the outset so that there is at least some consistency in naming and variable usage.
- Showing enthusiasm, appreciation, and honest feedback is really critical in keeping the team’s energy and momentum going.
- When using a framework such as React or Redux, DO NOT FIGHT THEIR PROCESS. As a beginner to these frameworks, don’t even think about trying to find a shortcut! Just follow their process exactly.
- For a team project, I would definitely use some sort of CSS pre-processor. We used SASS because others had familiarity with it, but what I really liked about it is the ability to make blocks of CSS (through mixins and variables) that can get re-used throughout each user’s individual CSS files. This made is so much easier to make design changes in one CSS file that impacted the entire project. For example, I made standard search boxes and headers to be deployed in all our tabs and these were incorporated into each person’s file. When I want to change the style, I can just adjust the mixin blocks and the changes will propagate throughout the site without me having to go through each individual CSS file. Also, every team should have descriptive variables for colors.
- In my role as PM for the team, I found that my job boils down to supporting the team by taking initiative for anything that requires it. For example, making a decision when the team is undecided, being the first to solve a teammates bug/problems, check-in on each persons progress and offer help, and adjusting the MVP/completed project as needed per the team’s progress.
In sum, Chingu was a great experience and I really loved working with my team. I learned way more with this team project than I could have by myself in the same time frame. Working in a remote team project also helps you learn critical job skills such as git and effective team collaboration. I highly recommend signing up for the next Chingu cohort!
PS — shout-out to Natasha Sadikin for letting me use her photographs in the project!
