Colab Calendar | Web

MERN Stack

Table of Contents

• Quick Start
  • Installation
  • Mongo URI
  • Dev server
• Tech stacks
• Contributing
  • Workflow
  • Directories Structure
  • Code Style
• Developers

Installation

git clone [email protected]:Colab-Calendar/web.git
cd web
npm ci --legacy-peer-deps

• ci respects package-lock.json

.env

An example:

DATABASE_URL=postgres://<postgres-username>:<postgres-password>@localhost:5432/collabify
FROM_NUMBER=<Get from Ben>
TWILIO_ACCOUNT_SID=<Get from Ben>
TWILIO_AUTH_TOKEN=<Get from Ben>
PRIVATE_GROUP_SECRET=<Any random string 8 - 32 chars>

PostGres

For Postgres to work as expected (assuming it's been installed and configured on your machine), you will have to create a database collabify in the psql shell

CREATE DATABASE collabify;

DB migration is needed, you only need to do this whenever there's a change in the db schema.

npm run db:migrate

To see the database, you can continue to use the psql shell with regular SQL queries, or you could use the GUI client provided by Prisma, to start this GUI, open a new terminal:

npm run db:view

Then head over to localhost:5555 in your browser (if it doesn't open automatically).

Dev server

To run a dev server:

npm run dev

If nothing is prompted, go to your web browser and visit http://localhost:3000

Tech stacks

For the tech we are using:

• Frontend

  • Next JS
  • CSS Modules.
  • MUI Bootstrap
  • FullCalendar, calendar API.

• Backend

  • Bcrypt
  • JsonWebToken
  • Prisma
  • Twilio handles messaging.
  • Jest, the testing library.

Additional resources:

• Getting started with git (thanks Aman!)
  • Learn Git Branching
  • Conventional Commits
• MDN: Documentations for modern web technologies.
• Learn X in Y minutes: A cheat-sheet for literally anything programming related, which includes JavaScript, and MongoDB queries (We are using Mongoose, which is an JS interface for MongoDB, the general idea is the same though).

Contribute

This section of the doc serves as an entry point for all future devs, it will be maintained and updated during stages of the development.

(Last update: Jan 12, 2023)

• Workflow
• Code Style
• Resources
• Documentations

Workflow

To prevent from becoming a self-fulfilling meme(s), here are the general rules!

1. Keeping it simple, tasks are going to be managed via the issue/ticket system on Github. The general workflow can be described as following:

   self-asign → new branch → code → create pull request → request review.

   • Issues and tickets are created for anyone to work on, just make sure to self-asign it before creating a new branch and start working on it. This is to avoid having multiple devs working on the same thing unknowingly.

   Note: if you are just staring out with Github, checkout the resources section.

2. When working with the backend PLEASE write tests for your code. If you are new to testings, your peers are more than happy to help.

• In /tests write a test for the function or file you made so the code reviewer can verify it works

3. Do not push/merge things directly into the main branch (unless specified by one of the team-leads).

   • Note that as of this moment, we have no way of enforcing this behavior, and while things are reversible with git, let's save us all some time and headache.

4. New issues can be created by everyone, and they are encouraged to do so. This is to keep track of development process:

   • If you find a bug, create a new issue. This is a way to notify other devs that there might be breaking changes in relative to their code that they need to plan around.
   • Fix and push your bug fix into a new branch, PR and link it to the issue (include close #<issue number> somewhere in your summary), request review, etc..

5. Although Github is used a lot in terms of task management, the main form of communication takes place in the Discord server.

6. As far as meetings concern, only the ones with breaking changes or of importance will be documented.

Directories Structure

• All stylesheets live in the /src/styles/ dir. Adding a dir for each pages, for example: All stylesheets being used in the homepage would go into src/styles/home/ dir.
• In /src/components if it is not a globally used component (only used in a certain page) then name the component after the page you are using it in. Eg: components/Home has components that are used in Home page
• /src/helper and /src/hooks are globally used (used in more then one file). If you are making a helper or hook for a specific component, please do that inside of the components folder. Eg: /components/GroupCalendar a helper function relating to it is put inside of the folder.

Code Style

Absolute imports

Absolute import path has been set up, the src dir is the starting point. For example, if you are working in ./src/pages/_app.js and need to import the globals.css stylesheet from ./src/styles/:

import 'styles/globals.css';

For a more detailed explanation.

CSS Modules

NEXT.js supports CSS Modules out of the box. It works very similar to regular CSS, you do not have to worry about potentially clashing class names. For a detail explanation, checkout the doc section.

A quick example:

// At the top of the file the index.js file
import style from 'styles/home/home.module.css'; // note the required `.module` extension
// ...
return <div className={style.anExample}>{/* ... */}</div>;

/* in home.module.css */
/* for javascript support, use camelCase */
.anExample {
  /* regular css code */
}

Developers

• Ben
• Aman
• Hal
• Ani
• Ekam