[Track 2/8] Project Setup

[taki-tiler[bot]]

Step 1/6 - Create a git branch

• Create a branch called feature/setup

If you don't remember how to create a branch, check the references in the previous issues.

Note: From here, the issues will contain fewer tutorials and step-by-step guides. However, it doesn't mean you won't be able to ask. You can always ask anything to any Taqtiler. We are here to help 😉

Note 2: Be patient, this is the last setup before coding. 👍

[sophia-bergamo]

finish

[taki-tiler[bot]]

Step 2/6 - Create a simple Hello World

Estimated time: 3 hours

Follow a tutorial project to create a minimal "Hello World" application using the technology stack you were assigned. If you don't know on which tech stack you are, please ask your tutor before continuing. We use react for web projects and react-native for mobile apps, both using Typescript. Below there are instructions for creating an simple Hello World in the tech stack you were assigned. So pick up yours and read it carefully:

React

• They have this awesome tutorial to start developing
• You only have to run npx create-react-app . --template typescript on terminal (your old README.md may be changed to README.md.old, just remove the new one and rename the old back to README.md)
• After running the command above, clean up some code to show only a simple "Hello World"

React-native

• Start with react-native setup tutorial to make sure you have everything you need. Use the React Native CLI Quickstart, so you can be closer to how a Taqtile project works.
• When the code setup is done, use the following command with typescript template: npx react-native init YourProjectName --template react-native-template-typescript (you may want to move your project files to the main folder (mv -r ./YourProjectName . && rm -r ./YourProjectName))
• After running the command above, clean up some code to show only a simple "Hello World"
• You can call it "done" after you're running it successfully on Android and iOS emulator (or device, if you prefer 🤓). Please open a pull request.

Note: For now on, some steps will have an estimated time to help you organizing your time better. If you do not finish the step in the estimated time don't worry! It's just an average time based on previous onboards. The main purpose of this estimated time is to indicate when you should ask for help in case you're stuck.

By the way, remember that if you're struggling with any topic, feel free asking any Taqtiler ;)

[sophia-bergamo]

finish

[taki-tiler[bot]]

Step 3/6 - Formatting code and conventions

Estimated time: 2 hours

So, now that you have properly setup and run your project, let's talk about some nice tools that we use to format our code and also some conventions we have. These are very important subjects when we work as a team, making our work of reading and contributing on projects much easier.

For this task, you are supposed to apply the following conventions on the basic app that you've created on the last step (rename some files and make sure that most of the files are following prettier and lint rules).

Lint

Lint is a very powerful tool to inspect code and warn about some possible mistakes. Lints use to be more language-specific. In our projects, we use eslint. Eslint is a Javascript linter, but sure we have some additional support for Typescript feature too. You can follow this guide to configure eslint with Typescript.

We recommend you install eslint VSCode extension, so the lint errors will be shown in real-time for you.

Prettier

Prettier is a tool that helps us formatting our code. It has a lot more options than editorconfig and language-specific formatting rules. They have a VSCode extension as well that makes possible to auto-format a file according to these rules. We highly recommend you install it, if it's not already installed in your pc.

We generally use prettier in our projects as a plugin for eslint, so code styling becomes something like lint rules. To add prettier in your project as a eslint plugin, please follow this guide.

This is the .prettierrc.js we use on our projects, in case you want to copy.

Conventions

Conventions are very important to maintain all projects code more readable for all developers and make the process of switching between projects less painful. We're going to list some of them here, but you will be learning and practicing them on code-reviews:

• We name our folders and files with kebab-case: lowercase characters and words combined with a dash (-)
• We name functions and local variables with camelCase: first char lowercase and words combined by the first letter at uppercase
• We name React components, Typescript interfaces, classes and exported objects with PascalCase: similar to camelCase, but first char is uppercase
• We don't use if without brackets, even if it's a one command only condition. This can avoid some readability problems

Add these tools on your project, check the code you have untill now to follow our conventions. Also, make sure that if you change something on code that generates a format or lint error, it's detected in real-time on the editor. Then, open a Pull Request.

[sophia-bergamo]

finish

[taki-tiler[bot]]

Step 4/6 - Create a Pull Request

• Open a Pull Request of your feature/setup branch

If you don't remember how to open a Pull Request, check out the references in the previous issues. Your PR should have develop branch as base, to be merged into later.

This pull request will be reviewed by your Taqtile tutor and possibly by some other people. This process is called Code Review (CR). You can ask your tutor who will be revising your code.

Mark them on every Pull Request as reviewers. Check here an example of Code Review. You'll possibly have some changes requested/suggested in order to merge your new branch on develop. Make sure to resolve all those changes before merging your branch into develop. 😉

[sophia-bergamo]

finish

[taki-tiler[bot]]

Step 5/6 - Update README.md

Estimated time: 20 minutes

Do you remember we created the README.md of this project before? Now that you have a project created on your technology stack, it's time to update it with some piece of information.

Since the feature/setup is (probably) still being reviewed, we need to create a new branch for this current step's task. Let's call this new branch docs/update-readme. Here's what you'll need to do:

• Go to develop branch: git checkout develop
• Open a new branch called docs/update-readme
• Update the Environment and tools section with some data about... well... your machine environment and the tools you're using. Things like the Node version, the Android Studio/Xcode version, the programming language any other relevant data for a developer to getting started in your project.
• The Steps to run and debug section is usually filled with information about how to run your project, such as what commands should the developer use or which configurations should he/she turn on/off before executing your project.

After that, open a pull request with these README.md changes.

TIP: an excellent README is that one document that is sufficient for any developer to be able to run and contribute to your project.

[sophia-bergamo]

finish

[taki-tiler[bot]]

Step 6/6 - Rebasing your branch

Here in Taqtile, before merging our revised (and approved) branches, we rebase this branch into the one we are attempting to merge. In this case, you'll rebase docs/update-readme or feature/setup to develop, depending on which one was reviewed and approved first.

Too confusing? Here are some good links you can read about rebase:

• Git Rebasing
• What is git rebase?
• Bonus: Merging vs. Rebasing

Note: Remember that if you are stuck in any of these topics, feel free to ask any Taqtiler. We are here to help 😉

The ideal setup we are trying to achieve with the rebases are something like this:

[sophia-bergamo]

finish

[taki-tiler[bot]]

Click here for your next track