Full-stack ReactJS app focused on streamlining employee shift management and customer relations.
https://shifts.it.wmich.edu/
Infomation is subject to change because of a future planned effort to provide a more intitive way of starting the project for the first time
If you trying to start a development build please modify the environment variables and the server config-file
which holds variables like database host addresses and ldap host, root passwords ..etc (More on this below)
To run a development build for contributing or testing whether your config settings are correct can be done by running the following commands.
-
npm install
(If you haven't already) -
npm start &
This will start the local react developed server on localhost:3000
-
node Server/server.js
This will start the backend server for which the proxy is already set up
Deploying a production build with docker is very easy. First thing you need to do is confirm that the exposed http port in the dockerFile
is the same as in server.js
.
Server.js - Changing the http port
let server = https.createServer(sslOptions, app);
server.listen(443, () => {
console.log("server starting on port : " + 443)
});
Server.js - Changing Certificate
const sslOptions = {
key: fs.readFileSync(__dirname + '/ssl/selfsigned.key'),
cert: fs.readFileSync(__dirname + '/ssl/selfsigned.crt');
};
once all config editing is finished we need to build the production version of our react build.
npm run build
This will turn our React development files into static js chunks which can be found in the newly created directory build
. Next we need to modify our server to statically serve the build folder.
Server.js - Switch to serving static files
app.use(express.static(path.join(__dirname, '../build')));
app.get('/*', function(req, res) {
res.sendFile(path.join(__dirname, '../build', 'index.html'));
});
more info can be found here https://create-react-app.dev/docs/deployment
you can now start your docker container. Run the docker container which will start 3 services the Mysql Database and the Node/express server, and adminer with the following command.
docker-compose up --build
Before getting into any setup it is highly suggested that new team members take a look at all of the references and coding standards. References can be found in: References/references.md
and programming standards can be found in: Standards/ProgrammingStandards.md
We decided on using Visual Studio Code (VS Code) as our IDE. To use the built in terminal (CTRL+~) we used git bash for windows versions and a regular bash terminal for Unix environments. The following standards should be followed:
- Tab spacing set to 4
- CRLF line endings
- UTF-8 character set
- Block Comments Package/Extension should be installed
This will provide universal comments for functions
Ex.
/**
* @param {type} parameter
* ...
*/
Function(args){...}
Within this IDE we also used a Pair programming feature that should be utilized as much as possible: VS Code Live Share. To set up Live Share it must be installed as an extension in VS Code. This feature allows for real time pair programming.
To clone the project from Github the following commands should be used from the terminal:
git clone https://github.com/JoeManto/OIT-CX.git
This command will copy the public project in a directory in your current working directory.
This file is store locally by a team member as it contains sensitive passwords for ldap and smtp. You will have get this file from a teammate
You will need to place this file in Server/
. This file is very important as it is imported by many modules throughout the server to provide easy access to database,ldap-auth,smtp configs.
Notice that this file is just a JS file that exports JS objects.
We need to make sure we have Node 8+ installed in the environment. To do so go to the following link for instructions for your OS: Install Guide
Before we install dependencies we need to make sure that the npm package manager has up to date packages.
Run npm update -g npm
to update Npm. This will update the underlining program to grab the most up to date packages.
This will install all the project dependencies that are referenced in package.json
npm install
Notice now a node_modules
directory will now appear in the root directory. This directory contains all the API's for the dependencies that we just installed. This directory also should never be pushed to the the remote repository as this file is really large.
All new dependencies need to be spiked and reviewed by all team members before they can be merged and used throughout the project.
To install MySQL version 5.11 go to the following link: Install Guide
A super user in MySQL is necessary to create the appropriate Tables needed by the project. To create a superuser in MySQL follow this guide: MySQL Guide
or run these commands in a unix terminal. If on windows then use the Mysql Command Line Program and skip to command 2.
mysql -u root -p
Notice that you will be prompted for a password. This is the password that was set when mysql was installed.
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password';
-
A database will need to be created that is called
nodemysql
. This can be done with the following command in MySQL within a terminal:CREATE DATABASE nodemysql;
-
Next, locate the sqldump.sql file within the server directory. Run the following:
mysql -u root -p nodemysql < sqldump.sql
. -
The tables should now be set up.
The following Programming Standards must be followed by all Team Members:
- All function names and local variables must use the camelCase naming convention e.g.
function doSomething()
- All class names and global variables must have the first character capitalized eg
class Solution{...}
- Constants should be named in all capital letters e.g
CONSTDATA
- Try to avoid digits within variable names
- All names should be descriptive and meaningful and represent what that variable or function is doing. e.g.
function addTwoInts(a, b)
rather thanfunction add(a, b)
- All functions should be visible within one viewing window at standard zoom in visual studio code
- If a function is larger than this it should be split into smaller functions
- Variables should not be one character other than indexing variables
- Tab spacing set to 4
- CRLF line endings
- UTF-8 character set
- Block Comments Package/Extension should be installed in visual studio code
- Use of white space should be as follows:
- Use a space after a comma when separating function arguments e.g.
function doSomething(arg1, arg2)
- Every nested block of code should be one indent further than the previous
- Use a space after a comma when separating function arguments e.g.
- Try to follow all of ReactJS Design Principles. These can be found at the following link: Design Principles
- Any react component that doesn't rely on multiple states should be a simple React component function
- All React Components functions/classes definitions should start and follow with a capitalized first character for each word
- Components should have a relatively small foot printing. Meaning they should one not be very large and too solve or implement a small feature (see nested Components)
Nested components should be used rather than passing in jsx through props in most cases ex.
- What not to do
<TwoColumn left = {[<div>LEFT SIDE</div>]} right = {[<div>Right</div>]} />
- What should be used
<TwoColumn>
<div>LEFT SIDE</div>
<div>RIGHT SIDE</div>
<TwoColumn>
Here is an example of what a ES6 React component function should look like. All react component functions and inner class functions follow ES6 syntax.
- return JSX only
let Frame = (props) => {
let {name,lastname} = props
return (
//jsx
<div>{name}{lastname}</div>
)
}
Here is an example of what a React Class Component should look like.
class Frame extends React.Component{
constructor(props){
super(props);
//state goes here
this.state = {
value:3,
...
}
}
render() return();
}
Prop Destructuring is the process of converting a js object's inner hash table key value pairs into individual local scoped variables. Prop Destructuring should be used always when there are > 1 number of props. This allows props to be referenced by name rather than using the root reference from props first. This process has little impact on performance and is mainly used for readability.
Prop Destruction in React Functions
let Frame = (props) => {
//Props Destructuring
let {name,lastname} = props
return (
//jsx
<div>{name}{lastname}</div>
)
}
Prop Destruction in React Classes
The process is almost the same as React functions, but instead of destructing to individual variables we just append the hash table from the props object to the class's inner hash table.
Prop destructuring in React classes should only be done in the constructor of the class in question. It also should be the first thing that is done in the constructor to prevent from future errors from a function using pre-destruction references.
class Frame extends React.Component{
constructor(props){
super(props);
/* [Props Destructuring]
* - this | Frame reference
* - {props} | Outer Destruction
* - ['props'] | stealing the hash table
*/
Object.assign(this,{props}['props']);
...
}
render(){
return <div>{this.lastname}</div>
}
}
No DOM element should be referenced out side of the React API.
Document.getElementBy...
should not be used at all as it interferes with the React API.
All element references should be done using React refs in components. (overkill example below)
class Frame extends React.Component{
constructor(props){
super(props);
this.link = React.CreateRef();
this.clickLink = this.clickLink.bind(this);
}
clickLink = () => {
this.link.current.click();
}
render(){
return(
<div onClick = {()=>{this.clickLink()}}>
<a href = "" ref = {this.link}>
</div>
)
}
}
Notice that a reference is attached to the anchor tag and that reference is used to simulate a click on the anchor when the outside div is 'clicked'
Any conditional statements in the render method should only compare changing state values and not any other global variables
Class Frame extends React.Component{
...
render(){
let state = this.state;
//One if
{state.somevalue === 1 &&
<div>Render Option 1</div>
}
//If else
{state.somevalue === 2 ?
(
<div>Render Option 2</div>
):
(
<div>Not 2</div>
)}
//nested if else
{this.state.firstRender
? null
: ( !this.state.closed ?
this.animateMenu(this.links,"up") : this.animateMenu(this.links,"down")
)
}
}
}
Follows the normal CSS styling conventions Styles that are local to a component should be implemented as javascript object styling. In line style in the jsx block
Javascript Object Styling define all the styling in the render method of the class component or use css modules
render(){
const divStyle = {
backgroundColor:'#333',
}
return (
<div style = {divStyle}/>
)
}
Inlining to not use
render(){
return (
<div style = {"background-color:#333"}/>
)
}
Correct Inlining to use
use camel case js style
render(){
return (
<div style = {{backgroundColor:"#333"}}/>
)
}
All JS based code in both the backend and in the React frontend should follow and use all ES6 Concepts. See: ES6 Reference
Such Concepts that should be followed are [Spreading Syntax (Array and Object referencing), Arrow Functions, Arrays.map, Arrays.filter]
Spread Syntax Example - from: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax:
function sum(x, y, z) {
return x + y + z;
}
const numbers = [1, 2, 3];
console.log(sum(...numbers));
// expected output: 6
console.log(sum.apply(null, numbers));
// expected output: 6
JavaScript Array Filtering Example - from: https://www.geeksforgeeks.org/javascript-array-filter/:
function isPositive(value) {
return value > 0;
}
var filtered = [112, 52, 0, -1, 944].filter(isPositive);
//JavaScript Arrow Function Example
var filtered = [112, 52, 0, -1, 944].filter(x =>{return x > 0});
print(filtered);
Output: [112, 52, 944]
All code in the backend should follow all the programming standards listed above in ES6.
Any backend service should be ideally separated as a child processes
- The main thread is reserved for REST API Requests
- A child process should only use a small amount of resources
- Always try to provide fallback properties for older browsers if they are known to be available
- Do not use comments unless the rule specified is unclear at first glance e.g. Some kind of workaround
- Put spaces before
{
in rule declarations - Use either hex color codes like
#000
or rgba() - Follow each CSS rule with a line of whitespace e.g.
- Use camelCase for all rule names
- Use a space after every
:
inside a rule
Putting these all together will yield the following:
#item1 {
color: #333
}
.selectedItem {
color: #fff;
display: block;
}
.testingClass {
border-radius: 5px;
background-color: rgba(255,0,0,0.3);
}
Below are all the respected standards and guidelines that must be followed through out the development of this project. The standards and guidelines will explain the proper ways to use git throughout all the know procedures that the team uses. It's Important that every team member follows these to ensure the code base has no concurrency issues with commits ...etc
Git was chosen as the Version Control tool for this project. This will allow the team to create separate branches for new features, testing and also allow for easy viewing of the file differences which is used as a tool for code review before any merges are made to the merge restricted branches. The online hosting service Github was also chosen for the hosting of the project files for the team. The team public repo can be found at the following link: OIT-CX Github. (See General Commands for retrieving the project)
- Merge Restricted Branch : A branch that only allows commits from the lead contributor or contributor's
To initialize the Repository use one of the two commands can be used
git init \
git remote add origin https://www.github.com/joemanto/OIT-CX \
git pull origin master \
or
To directly cloning the repository, use this command
//clone
git clone https://www.github.com/joemanto/OIT-CX
When starting a new feature or sub-feature, a branch can be created from the testing branch or a from a sub branch from testing.
-
Sub-feature branching is not required, but is used throughout the project.
-
Feature branching from the testing branch is required.
Branching from testing
git checkout testing
git branch <branchname>
Branching from sub branch
git checkout <subbranch>
git branch <branchname>
- Before any code can be merged to master the following must be done
-
All server and frontend side tests should all pass
-
All code has to be development and pushed to the testing branch before the code can be pushed to the master branch
-
All code should go through a code review with another team member (see code review section)
-
-
A sub-feature branch is only allowed to be merged back up to the root feature branch. No Higher
-
A feature branch is only allowed to be merged to testing. No Higher
Merging to master
Testing branch merging will be handled by the lead contributor's via Github pull requests from team members
or
lead contributor's can merge after code review by the following commands
git checkout master
git merge testing
Merging to testing
git checkout testing
git merge <feature-branch-name>
All commits should
- have small file differences and only contain file differences that relate to the context of the commit that is bring created.
- have a detailed message or paragraph that explain the insertions and deletions. follow this guide for writing commit messages
Don't directly push to the master branch This practice allows for possible inconsistencies throughout the code base and could result in merge conflicts or cause bugs because the new changes caused tests to fail.
Pushing to Branches
git add -A
# short message
git commit -m "message"
# or
# paragraph message
git commit
git push <remote> <branch-name>
If any code is pushed to the Master branch without being reviewed and tested (both unit and system tests), that push will be reverted and the project will be taken back to the most recent stable version. The code that follows will perform a rollback:
git push -f origin last_known_good_commit:branch_name
To revert an individual commit that was either made by mistake or incorrect, perform the following:
git revert <commit hash>
Before any major changes the team will need to engage in a short Pair Programming review session This can be done either in person, or in real time using Visual Studio Code Live Share. We opted for this since the team is small
- In this code review the tests for the project will be ran before the code review starts.
All team members are allowed to push to the testing branch and everything lower without a code review.
- Features when completed and tested should then be pushed to the master branch after a code review
Allow the guide for pushing to branches in (Commits)
The following guidelines and standards below will explain how, when, and where Server tests and React Component tests are conducted using
- Jest
- jest-dom
- React Testing Library
- React Test Render
Unit Tests need to be conducted for every finish Non-Static Html React component and every function should ideally should have a Jest t associated to it.
- All tests need to be in the directory named
__tests__
This folder name will allow jest to automatically find unit tests. Alternately, tests can have the file extension prefix `.t.jshich will also allow jest to spot tests. - Example Jest t file name would be the following `spiketest1.t.js- The testing file should have the same file name prefix as the file that is being tested
- The testing file should not contain tests that are from unrelated files
A suite in Jest is simply a category name for all the tests in that suite and is denoted by the keyword describe
- For
Testing React Components
the suite name should be the component name - For
Testing normal functions
the suite name should be the function name - A suite should contain all the tests that are directly related to the element/function/class that is being tested
describe(('suite name'), () => {
it('should ...', () => {
....assertion
})
})
A t in Jest can be denoted by it
or t
. Jest tests can be done by using an expect combined with a matcher. Jest provides a whole list of matchers that t general logic conditions all the way up to DOM lookups. These Jest Assertions can be done by using the expect()
with the element or value that are going to match.
then
- The it keyword should be used
- The t name should start with "Should ..." as it provides a nice way of making sure unit t descriptions are easy to understand.
Example Test with Jest
const functions = {
add: (num1, num2) => num1 + num2
}
describe('Add', () => {
it('Should Add 2 + 2 to get 4', () => {
expect(functions.add(2,2)).toBe(4);
})
it('Should Add 5 + 5 to not get 11', _ => {
expect(functions.add(5,5)).not.toBe(11);
})
})
The Jest unit tests can be ran using the command jest
. Jest then takes a path to where you tests are found jest path/to/tests
.
jest spikes
To run the unit tests for the frontend you run
npm t
this will run all the tests in the src
directory, which holds all the react components.
-
System testing is automated through Jest by using a global call of jest. This can be done with the following command:
jest
(in the root directory) -
This will search through the entire directory of the project and find any file with the extension `.t.jsThe output will show the number of tests that were found and ran along with the number of them that passed.
-
Snapshots can also be created for components using Jest (more on this later). All snapshots will also be ran using the
jest
command.
- We use jest to automatically generate coverage reports using the following command:
npm t -- --coverage
Test Suites: 2 passed, 2 total
Tests: 2 passed, 2 total
PASS src/__tests__/JestSpike1.t..js
PASS src/__tests__/App.t
----------|----------|----------|----------|----------|-------------------|
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s |
----------|----------|----------|----------|----------|-------------------|
All files | 0 | 0 | 0 | 0 | |
----------|----------|----------|----------|----------|-------------------|
Test Suites: 2 passed, 2 total
Tests: 2 passed, 2 total
Snapshots: 0 total
Time: 6.146s
https://jestjs.io/docs/en/snapshot-testing - Testing components using snapshots in React with Jest
Coding standards and guidelines </br>
https://www.geeksforgeeks.org/coding-standards-and-guidelines/
CKAN CSS Standards </br>
https://docs.ckan.org/en/ckan-2.7.3/contributing/css.html
CKAN JavaScript Standards</br>
https://docs.ckan.org/en/ckan-2.7.3/contributing/javascript.html
ES6+ Programming Reference </br>
http://es6-features.org/#Constants
React Code Standards Guide </br>
https://css-tricks.com/react-code-style-guide/
JavaScript Spread Syntax</br>
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax
JavaScript Array Filter</br>
https://www.geeksforgeeks.org/javascript-array-filter/
Git Commands / Tutorial</br>
https://www.atlassian.com/git/tutorials/undoing-changes
Git Commit Messages Guide</br>
https://medium.com/@steveamaza/how-to-write-a-proper-git-commit-message-e028865e5791