Developer Guide

Development

We are editor and IDE agnostic in this project. You can use whatever editor or IDE you normally use. If you have not chosen a editor or IDE, we have Visual Studio and Visual Studio Code settings files included that will help you get going to work on this very easily.

Our stack is:

Front-end:

• REACT 18.2
• MUI v5 (UI Library)

Back-end:

• NodeJS latest LTS
• Express 4
• SQLite 3

Tests:

• Cypress
• Jest
• RTL

This app was bootstrapped with Create React App.

It is not hosted anywhere yet.

Coding Style and Naming Conventions

TODO: add coding style conventions:

• Think on current coding style conventions we've been following and add them here.

Front-end:

Components:

• Components that are intended to be used as reusable components should be named as <Custom[ComponentName]> so a reusable Alert component should be named CustomAlert.
• We name component files the same as the components they represent with an .jsx extension so CustomAlert.jsx.

CSS:

• We name CSS files the same as the component they belong to so the CSS file for the Post.jsx component would be Post.css.
• We name CSS classes using the BEM naming convention in the following manner:
  • .Componenent__inner-element: So that for the Post.css the rule styling the close button would be written as .Post__close-button.

Back-end:

Database:

• We name our database tables with singular and uppercase names: User, Post, Event, Friendship, etc.
• We name our database table fields camelcased: date, title, locationName, imageUrl, etc.

Routers:

• We name our routers <[CRUD action of the router][modelName]Router> when importing them on server/app.js. A router to add a new user post would be named createPostRouter.
• The exception is with Read actions instead of calling a router say readPostRouter to get all user's posts, it would be named getPostRouter so use get instead.
• We create folders for different routes and give them model names: /users, /posts, /events, etc.
• We names router files <[CRUD action of the router][modelName]>.js so getPost.js or createPost.js or updatePost.js or deletePost.js.

Endpoints:

• We name endpoints /api/[modelName]/[:id] (in case id required) so for Event models CRUD actions endpoints /api/event/:id would be used.

End-to-end Tests:

• We separate our test in 2 folders UI and API depending on the kind of test.

• We name test files <[(functionality|component)to test].cy.js> so a test for Login User functionality test file would be login-user.cy.js and a test for Add Post functionality would be add-post.cy.js but a test for Create Post API endpoints would be create-post.cy.js.

• Test cases are named using the "Verify behavior occurs" naming convention. So:

  • "Verify user stays logged in after page reload" or
  • "Verify user cannot login with invalid credentials" or
  • "Verify a post is created when submitting post form" or
  • "Verify a post is removed when clicking on the post's close button"

  ...are all valid names.