oneleif / olwebsite-react Goto Github PK

HTML Naming Conventions

Naming Style of ids

• id should be in camelCase

• Example id="fakeId

Reason: most common convention and will make the id look different from classNames

CSS Naming Conventions

Naming Style of class names

• class name should be in kebab-case

• Example className="fake-idd

Reason: most common convention, able to tab between each word in a CSS file, Also, using hyphens allows you to take advantage of the |= attribute selector, which selects any element containing the text, optionally followed by a dash:

span[class|="em"] { font-style: italic; }

Javascript Naming Conventions

Naming Style of class names

• variables should be in camelCase

• variables should be descriptive, avoid shortening names to keep names informative

• Example let exampleName; instead of let exName;

Reason: With a large code base and hope to have a lot of devs, having descriptive names with help newer and younger devs know what's going on

Naming Style of constants

• constants should be all caps

• constants should have underscores to delimit spaces

• Example const EXAMPLE_CONSTANT = "example"; instead of const exampleConstant = "example";

Reason: makes constants identifiable and readable, gives a good description of what they are or what they're used for

We would like some beginning coding standards to be written up in the Wiki and submitted for PR so that we have standards for new members.

Code Blocks to be used above variables, consts, functions, and render

Example:

  /************************************
   * Constants
   ************************************/

  const EXAMPLE_CONST = "example const";

export default function ExampleComponent() {
  /************************************
   * State
   ************************************/

  const [exampleState, setExampleState = useState();

  /************************************
   * Life Cycle Hooks
   ************************************/

   useEffect(() => {

   }, []);

  /************************************
   * Functions
   ************************************/
  
   function exampleFunction() {

   }

Reason: This would help encapsulate the functionality/purpose of the code underneath these blocks

React Component File naming:

• Should be contained in Folders that are in PascalCase

• Should have .jsx extenstion on files that contain React/JSX

• Should be written in PascalCase

Example:
(contained in src/components/MyComponent/MyComponent.jsx)
MyComponent.jsx

Reason: These are the most common naming conventions when it comes to react

Javascript File naming:

• Should be contained in Folders that are in kebab-case

• Should have .js extenstion on files that contain strictly Javascript

• Should be written in kebab-case

Example:
(contained in src/components/compent-utils/component-utils.js)
component-utils.js

Reason: These are the most common naming conventions when it comes to javascript that I've worked with

Currently using a react carousel but it seems to be deprecated. I think it would be better if we created our own carousel. Would allow us to have more control, be able to customize it more

Currently on views with no or small amount of content, the page body is not fitting the full screen. It shows a ton of white space

Show a global map (pannable/zoomable) with pins for locations fed from the user API.

See install details here: https://github.com/testing-library/react-testing-library

Currently on a successful user login the user is redirected to the landing view. Before this occurs we will need to take the user credentials off the response header and store them in the window. These values will be the user email, the session token and the expiration date the session tokens

When the user logs out, we also need to make sure that all previously saved authentication information is removed.

Look into potential markdown interpreters to use for blog posts, I'd say mess around and see what's out there. It would be interesting if we wrote our own interpreter, feel free to get crazy with it.

Will need to disable ability to submit until inputs are valid. For email and password inputs

Waiting on Search API and styling.

Useful to show the most common tags (for posts) or languages (for active projects)

container that will hold the filter, having this will help with the styling of the rest of the page

Until designs are made, just use the API to get the requests working and don't worry about the look of the page, that will be a different ticket

The profile page should list fields for all of the information in the User interface, see the API here: https://github.com/oneleif/olWebsite/wiki/API-Interface-Documentation

There should be a button to toggle the page into an editable form which saves the profile updates in the form upon submission.

Need to follow the https://oneleif-olwebsite.vapor.cloud/ website and add the discord and github links to the join us container on the landing view

In the future it would be nice to have a way for non-developers to submit bugs through the website itself.

The top nav bar should always stay on screen. As a good place to start, look into sticky headers/elements in CSS.

We need a context that stores the values received after the login authentication. This context will then be accessible globally to all components that import it.

With the "best practices css" the links were changed from a full div to just text. These links need to change color on hover (probably become more opaque) to show they are clickable. Use the activeClassName field on the Nav Link to apply this css.

Working on any oneleif repository or active project should be standardized. The following are guidelines to make a project easy to work on.

ONLY the initial ticket should be made on the Master branch.

All tickets should be merged into Develop branch

All tickets should be done on their own Feature/feature-name branch

Pull requests should pull from the Feature branch into the Develop branch.

Pull requests should require reviewers (2+) and are enforced even for admins

All Git repositories should have a detailed README and Wiki with info on contributions, or point to the oneleif Open Source contribution standards.

All oneleif Active Projects should contain the oneleif footer in their readme and/or wiki.

Pull Requests should be make directly in the repository for oneleif members RATHER than a forked repo for ease of testing by reviewers.

when a PR is made, a CI check should be added to make sure:

• the issue number is in the commit message
• the ticket is in progress,
• the ticket is assigned to the person creating the PR

Currently they are two separate components, which seems a bit unnecessary. Would be nice to refactor it one component that changes CSS based on size of screen

The linter should prevent most trivial compilation and styling mistakes. This is the first pass at setting up a customized linter.

Will need to have the toolbar match the most recent mockups

Currently we only check if a password input is empty or that the password matches the reentered password. Will also need to check that the password meets our set validation:

• length of 8 or greater
• contains a lowercase letter
• contains uppercase letter
• contains digit
• contains special character

https://mdbootstrap.com/docs/react/navigation/hamburger-menu/

Function Documentation

Above each function

/**
* Description of function goes here
*
* @param {<Type of Param>} <Name of Param> - <Description of Param>
* @returns {<Type of Returns>} <Name of Returns> - <Description of Returns>
*/

Reason: Classic JS docs, i think it's self explanatory

State Documentation

Above each state

/**
* Description of state goes here
*
* @type <Type of state>
* @default <default value if there is one>
*/

Reason: i think it's self explanatory

The carousel overlaps styling underneath it and does not respond well to different sized screens

Implement a fetch wrapper that passes in the needed params to perform a fetch to the backend. This is to make the code base prettier

This is waiting on the rest of the designs to be done so that we can see how the style would be affected by changing themes.

Will need to make a view for when users type in the wrong url. This will need to say their desired page isnt found. Kind of goes hand in hand with #38 and should resemble the example given from the react-router-dom:

https://reacttraining.com/react-router/web/example/no-match

https://stackoverflow.com/questions/36904185/react-router-scroll-to-top-on-every-transition

Currently if the link is changed, the view will stay at the same point on the previous page.
Acceptance criteria: view returns to top of page after link clicked

Jest and React Testing Library

We would like some beginning coding standards to be written up in the Wiki and submitted for PR so that we have standards for new members.

Even though the dynamic link has changed on the toolbar from sign up to the user icon, users can still reach the /sign-up and /login paths. Will need to have a check on initial load of views to check the UserProvider Context to make sure there is no current user logged in and prevent going to the view if so

Functional components seem to be agreed upon as the first standard.

We would like some beginning coding standards to be written up in the Wiki and submitted for PR so that we have standards for new members.

Until designs are made, just use the API to get the requests working and don't worry about the look of the page, that will be a different ticket

Declaring Functions with keyword 'function'

The Debate:
When writing with React I've seen two different approaches to writing functions

const update = () => {

}

&&

function update() {

}

Proposal:
To use the latter function that uses the keyword function

Reason: Easier to scan component for functions, especially with a large file. These functional components all start to look the same and this will help functions stand out

Will need to show some sort of message when an empty string has been entered into the search box that will prompt the user to enter a value

• The use of functional components instead of class components

• using the keyword function and default export on same line

• imports at top of page (whitespace between different types of imports)

• constants above component

• useState at top of component

• useEffects under useState

• functions under useEffects

• render at the bottom of the page

Example:

import React, { useState, useEffect } from "react";

import Example from "example";

  /************************************
   * Constants
   ************************************/

  const EXAMPLE_CONST = "example const";

export default function ExampleComponent() {
  /************************************
   * State
   ************************************/

  const [exampleState, setExampleState = useState();

  /************************************
   * Life Cycle Hooks
   ************************************/

   useEffect(() => {

   }, []);

  /************************************
   * Functions
   ************************************/
  
   function exampleFunction() {

   }

  /************************************
   * Render
   ************************************/

  return (
    <div>
    </div>
  );
};

Reason: Using the function instead of the es6 method allows everything (parameters and export) to be on one line and helps the functional component stand out more. Life cycle at the top allows to see the actions performed on useEffect quickly and easily. Render at the bottom keeps a uniform file and no other reason lol

When writing if/else if/else statements

• statements are on their own line

• spacing between if and bracket

if (/*logic*/) {
   //perform action
}
else if (/*logic*/) {
   //perform action
}
else {
   //perform action
}

• nested if statements are tabbed over as such

if (/*logic*/) {
    if (/*logic*/) {
       //perform action
    }
}

Reason: Allows for code readability and looks very clean; which is very important when trying to have a large group of people working on the same code base

Will need to implement a generic error well that will take in a message and boolean if there was an error or not (Display Error Icon if So). Currently need an error well implemented for the "Page Not Found View"

The header should show, for example "dashboard" when a user is logged in, but not when they are logged out.

Follow the mockups to create a login page: https://www.figma.com/file/mTy2TSSWVpAiuoirWb0ofo/oneleif-web?node-id=0%3A1