Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime. What I learnt is how to learn something totally new.
The 11th&12th week in Makers marks the end of my short 3-month in Makers, as after this final project I will officially graduate from Makersacademy.
The final project is quite flexible in terms of the theme and tech stack. Working as a team of 6, we picked our theme to be environment-protection and tech stack to be MERN.
The idea is quite simple: we want to built a transport app for the environmentally conscious which allows users to search for a ground or flight journey (the search result integrates data from 3 different API services to show mode of transport, distance, duration, maps, and carbon emissions for each route), and see the breakdown analysis of their history journey in a personal dashboard. (Visit our live app on heroku)
Simple as the idea sounds to be, the difficult was far more than I imagine. In reality, we were learning something complete new and use it to build our app in 2 weeks.
MERN = MongoDB + Node.js + Express + React
The whole project is divided into backend (MongoDB, Express) and frontend (React) within the Node.js environment. For me personally, I was responsible to implement the features below:
- Core components in the React to render the form and display the data in a table format
- End to end implementation of configuring MongoDB and the build of 2 collections (user and travel), defining the controller actions and relevant routes
- Front to back implementation of user authentication (front-end user login/signup/logout, backend writing user into database, retrieving relevant user data, front to back authentication using passport.js and JWT)
- Navigation bar component and react router setup
Quite a lot right? Not an easy learning curve. I can easily turn this blog into a list of all new knowledge points I learnt in the 2 weeks which will fill the gaps. But I believe the importance is not to just share knowledge everyone can find on the internet, but to share reflection of how I learnt knowledge.
In the process, I found the following points particularly useful which I will illustrate soon.
- When you have no idea where to start, find a tutorial as close to your feature as possible, and learn by doing
- Read the official documentation carefully, even you don’t understand at the beginning the terminologies and references, but at least to have a rough memory so you know where to look up when you stuck
- When time allowed, read more than is necessary. Even you don’t need that piece of knowledge now you will need it in the future
- Always communicate with others, coaches, teammates, don’t code alone when you get stuck for too long
- Follow a good debugging process, this will save you tons of time when you are struggling to figure out which line of the new feature is not working
When I first started to build the MongoDB database and connect it to the express server, I have not a clue where to start. After reading a few pages in how MongoDB is different to relational database, I found myself stuck in concepts and theories. So I started to search some MERN tutorials focusing on the database part. Since what we want to build was pretty basic, it wasn’t hard to find a blog about how to build a MongoDB
to-do list database just like our
travel record database, so I hit the road by building our own database by mimicking the tutorial. I paid particular attention to anything that is different to us and I tried to understand line by line the code in the tutorials and tweak the code to make it suit our project needs.
Whenever you find yourself lost in theories and concepts, start by doing is a good option.
Before I built my first react component, I spent one hour to quickly go through the official guidance(highly recommended), 70% of the code and explanation doesn’t make sense to me as my only understanding of React that time was it comprises of various components. However, important concepts like states and props did leave some mark in my head, so later when I needed to pass arguments between parent and child components, I quickly found the reference to states and props in the official documentation.
So always go through the official documentation quickly the first time you use a new tech, and pay attention to the main features that make this tech unique.
When I needed to pass data from parent to child component in React, I read a few medium blogs articulating this problem. However, the question arose to me regarding how to do it vice versa, aka passing data from child to parent? I didn’t have urgent need to know the answer, but I was really curious about it and spent a night doing some reading about. It turns out that in order to pass it from child to parent component, you need to insert a callback as props into child component.
Interesting, later on, when I was building the navigation bar component in React, I came across the problem to make the navigation bar component conditionally hide and show the signup/login vs logout options based on the user’s login status. Yet the user login component is another child component which can not pass props directly into its sibling — navigation bar component.
It suddenly occurred to me the reading materials on this issue earlier, and after 2-hour digging around, I finally implement a solution to let the login component pass data to its parent App.js component using callback, and then from App component to pass the data as normal props to one of its child — the navigation bar componenet.
Without having read about the extra materials, I would not have thought of the solution so quickly. So always read a bit more than necessary.
I know it’s common to immerse yourself in a problem and fight with it for a whole day, but don’t do that! There are numerous times during the group project when I came across the final answer to the problem when pairing with one of my team mates.
Even most of us as fairly new to the technologies we used in the project, but surprisingly there’s always at least one person can shed some lights on an issue when everyone got stuck.
I also enjoy to chat with coaches, if not for a particular problem, I’d like to walk through my codes, and they can always spot some high level design problem.
So never code alone, share your happiness and make it doubled, share your struggles and make it halved.
As the code base grows bigger and bigger (across front- and backend repos and different folders), it becomes more difficult to debug. I tend to put a lot of
console.log so I can have a full loop of the code that get executed, then I can narrow down to that specific code block that isn’t working.
This happened when I tried to figure out if a JWT token was sent from the backend to the frontend when the user logs in. So I start from the post request at the frontend,
concole.log the request, I then
console.log the request and response from the backend. Working this way allow me to know if it’s the backend not sending the token or it’s the frontend not saving the token (turns out to be the former).
So follow a proper debugging process however scaled up the project is.
So that’s it!
Looking back the 12-week at Makers, there’s too much to say about. What I learnt most though, as I said earlier, is not those hard knowledge, but a methodology to be able to pick up a new skill or a technology quickly.
I would rather not to have a closing statement at this point as I know it’s only the end of a short period, and there’s much more exciting stuff for me to explore, to learn, to build.
It’s the finale. It’s the prelude.