(This story is part of the weekly assignments for my internship at Nearsoft. I hope that some of the insights I learned this week can help others in their learning journey. Previously: Month 3, Week 1.)
This week, I worked on an open source React issue and, I am happy to say that I successfully made a Pull Request, got it Approved and Merged. However, before this, I spent more than a couple of days looking into other codebases. This taught me how different projects are structured, some design patterns and I got the chance to set up more than a handful of development environments.
After a week of mostly reading and learning from other people’s code, these are some of the week’s insights:
MVC is a design pattern that allows us to build powerful and reusable applications by separating the responsibilities of our code. This design pattern can be used in any programming language and can help organize code as well as isolate errors.
To achieve this, the following directory structure can be used:
index.tsxwill act as a Router for our
foo.reducer.tswill handle the actions of our entity using axios and dispatchers. This will be the Controller.
foo.tswill render the User Interface. This will be the View.
foo-update.tsxwill render further User Interface modals. These will also be the View.
If Open Source projects were books, the Read Me file would usually be the back cover, prologue and sometimes even the index. This file includes vital information of the project and also serves as a reference to important links for development. Also, often times, the Read Me has information on the types of contributions you can make as well as a link to the
CONTRIBUTE.md . This is the starting point of your search whenever you first open a project and it’s value to represent your project should never be underestimated.
These are some examples of
README.md's I stumbled upon this week:
This file sets expectations about the project regarding what kind of contributions are being accepted. Here can also be found information about how to get in contact with the core team of the project. Sometimes the project will have a Slack channel, Gitter community or Private forum. Sometimes it won’t. However, for open source projects it’s important to discuss matters and talk triage of the development within the issue’s public page. This allows for the rest of the community to have access to the information as well.
When you’ve reached this file, you are ready to open your iTerm.
This file includes information of the commands you will need to use in order to set up your development environment. This is when you make sure the npm, yarn, or language version is aligned with the project’s. Or, if you choose to use Docker, it’s time to build and run the containers. Some lucky times, the project will have great documentation. Sometimes, there won’t be more than a couple of lines to help you get started. However, what’s important is to always read this and other developing guidelines before getting started. This will probably help save time on the long run and help build expectations of the whole Developing process.