For my projects management

general-guidelines.md

Some good practices I'd like to stick with it

• Recommend using Sourcetree client, but you can choose anything.
• We use GitHub flow for simplicity. Reason here. In short:
  • Always branch from master.
  • Name the branch accordingly, read below for more information.
  • After passing all tests, ask for reviews.
  • Merge back to master. Enjoy productivity!
• PR’s name format: CODE-123-Descriptive-task-name-here
  • CODE: in our case, for example, THDP is for Triết Học Đường Phố.
  • 123: the code of the issue/task.
  • Descriptive-task-name: Convert from task’s name.
• Commit messages should be descriptive and meaningful.
  • Try to avoid “WIP”, “yup”, “Todo”, “Still not working” at all costs.
  • Only commit related work. If you find a bug out of the current task’s scope, create a new task for it.

Code style

• Strictly follow the ESLint. We will use eslint-config-airbnb.
  • If you want to change some rules, bring them to discuss with the team first.
  • You have to pay 10,000€ for using the eslint-disable-line once!
  • Try to avoid putting console.log into production if possible.
• Try to use names with meaningful words.
  • Good:
    • const shouldDisableApplyButton = checkPermission(...)
    • selectedItems.map((selectedItem: ListItem) => renderItem(selectedItem))
  • Bad:
    • const disabled = checkDis(...)
    • items.map(i => rItem(i))
• Avoid complex one-liner code and nested ternary operators.
• Try to avoid using string directly. Embrace enum, constant, dictionary map, etc.
  • Good: const errorMessage = 'Something ...'; then throw new Error(errorMessage);
  • Bad: if (error) { console.log('Something wrong ...'); }

TypeScript

• Avoid using any at all costs. Same with extends object, {}.
• Avoid using @ts-ignore. This line costs the same eslint-disable-line!
• Names should be descriptive and meaningful.
  • Avoid { ctx: CT }. Should be: { context: ContextType }
• We prefer to use type rather than interface if possible.
• Read more Do and Don’t from TypeScript documentation.

Testing

• We use react-testing-library with Jest.
• Avoid using fireEvent if possible, try to use user-event
• Try to cover behaviors instead of simply checking visuals.
• Read this blog to avoid common mistakes. This is really important.