This repository is for Class13 Final Project - Chattie
Production website: https://chattie-production.herokuapp.com/
Staging website: https://chattie-staging.herokuapp.com
Class Dates
Graduation Wednesday 21/10
Study groups dates
Until further notice, please attend the remote study groups with Elastic and Zendesk
Niels Schmidt from Anna is the customer for this project
Add here information about the Business Glossary Business Glossary
Check the DB Model Diagram here
Check the mockup here
Go to the project board here
console.log
Generally there are 2 types of components: presentational and container components. Please review the differences below:
Presentational components | Container components | ||
---|---|---|---|
Also known as | "dumb" components, functional stateless components | "smart" components, stateful components | |
Lives in this folder | /components |
/containers |
|
Purpose | Determines what a component looks like | Determines how the applications works | |
Communication | Can only communicate by receiving and passing props | Can communicate via props, can call APIs, can manipulate the DOM with REFs, etc. | |
Markup | Contains most of the markup for the application | Should generally have as little markup as possible. A container <div> or an <ul> tag is ok, but if you need more, consider making a separate presentational component |
|
Storybook | Can easily be mocked in Storybook | Cannot easily be mocked in Storybook, would require mocking API calls, etc. | |
Can have side effects | No | Yes |
These are general distinctions. In the past you could only make container components as class components as functions could not have state, but with React Hooks functional components can now have state. And with the addition of Context API components can easily communicate with their siblings and jump multiple steps in the hierarchy outside of how props are used to communicate between components. This is very powerful and can be convenient, but can easily make the application overly complex, so the advice is to stick to the separation between Presentational and Container components as closely as possible and only apply for example Context API where there is a justified need.
It is highly recommended, but not a requirement, to add proptypes to your components. Proptypes does two things:
To add proptypes, simply import the proptypes package and specify exactly what data you expect your props to contain on the propTypes property of your component:
...
import PropTypes from 'prop-types;
...
[your component code]
....
YourComponent.propTypes = {
firstProp: PropTypes.string.isRequired,
secondProp: PropTypes.number.isRequired
}
Note the capitalization in the example above. It's easy to get wrong. Refer to the proptypes npm package for further documentation.
Checkout this great video from Zaki Wasik: https://www.youtube.com/watch?v=_AZhtGTWN8k
Storybook provides a sandbox environment where it is easy to mock components in a visual way. When you create a presentational component you should always add a story so it shows up in storybook. Benefits of using Storybook is:
Storybook runs as a separate web application parallel to the main application. Run storybook with the following command
npm run storybook
The storybook application will become available on http://localhost:3007. From here you can browse and review the available components.
Some components may have "knobs" which are UI controls that allows you to interactively play with the props of a given component. It is up to the author of the component to set up knobs.
Checko out this video: https://www.youtube.com/watch?v=jjH1cKGkt3o
The most basic way to create a story for your component is to put this code in your the stories file for your component (my-component.stories.js):
import React from 'react';
import MyComponent from './my-component.component';
export default { title: 'Some title' };
export const basicStory = () => <MyComponent firstProp={1} secondProp={2} />;
If you open Storybook, you should see your component under the headline "Some title".
You can have multiple Stories (i.e. multiple mutations of the same component) in your stories file. Just add another export. The story will take its name from the exported variable name:
...
export const basicStory = () => <MyComponent firstProp={1} secondProp={2} />;
export const advancedStory = () => <MyComponent firstProp={() => callMagicFunction()} secondProp={{ ...mysteriousObject }} />;
This will result in two stories under the headline "Some title".
You can also add folders to add hierarchical organization to your stories:
...
export default { title: 'Secret Folder/Some title' };
...
You can add "knobs", i.e. form elements that will allow you to interact with your component by manipulating props in real time, by importing withKnobs
from the @storybook/addon-knobs
package and using it as a decorator.
import React from 'react';
import MyComponent from './my-component.component';
import { withKnobs, boolean, number } from "@storybook/addon-knobs";
export default { title: 'CardLayouts/Status Card', decorators: [withKnobs] };
export const WithKnobs = () => <MyComponent isTrue={boolean('Toggle is true', true)} theNumber={number('Change the number', 42)} />;
Boolean and number which are also imported are widgets to manipulate the props. Boolean will provide a simple true/false checkbox and number will provide a number input. But you can add many different knobs, including dropdown selects and color pickers.
Always think about how you can break your UI into meaningful reuseable components. On one hand you want to be able to re-use your code as much as possible and on the other you want to avoid premature abstraction into components, meaning that you don't want to create a lot of components that are never actually re-used.
Please refer to this article for the basics about breaking UI elements into components.
MotorcycleList
, not ListMotorcycle
. This way components will be grouped by domain when sorted alphabetically in a folder. If it is a generic list component that can contain many things, omit the domain and call it List
./Components
and postfix their name with .component
./Containers
and postfix their name with .container
./MotorcycleList/MotorcycleList.container.js
/MotorcycleCard/MotorcycleCard.component.js
/MotorcycleCard/MotorcycleCard.styles.css
/MotorcycleCard/MotorcycleCard.stories.js
/MotorcycleCard/MotorcycleCard.test.js
PascalCased
.PascalCased
by general React conventions. Don't include .component
or .container
in the JS name.For global styles (i.e. styles that shall affect all components) use src/client/index.css
. Global styles should be very rare and should typically be reserved for things like CSS resets, importing fonts and utilities.
For theming, use the file src/client/theme.css
. Theming covers everything related to the visual presentation of the site that needs to be re-used often. That means colors, borders, paddings, shadows, etc.
Components should always have a unique CSS class to make it easy to apply styles and styles. For example the "label" component should have a class "label". To easily concatenate different classes or apply classes conditionally, use the classnames
npm package. Example of a label component that has a class "label" and will receive additional classes as props:
...
import classNames from 'classnames';
export default function Label({ title, className }) {
return <span className={classNames('label', className)}>{title}</span>;
}
...
Only put styling that is relevant to the individual component in the component CSS file. If it covers multiple components, put it in theme.css
or index.css
.
Generally components should be styled using a dedicated stylesheet per component (see naming conventions in the section above). Exceptions can be made for values that are dynamically updated - i.e. a width that can any arbitrary value. If you need to change between two colors, apply css classes to the element in question style those classes and use react to switch out the css classes. For example:
.label-primary {
background-color: var(--primary-color);
color: var(--white);
}
Follow these best practices for coding: HERE
This can be used as a checklist for every PR you make. Go through the list and see if you have used all the best practices
Working with Heroku and Deployment
When running the API, you will automatically be running the API Documentation which is based on Swagger. Just go to localhost:3000/api/documentation to read the specifications for the API.
You can use your api token to authorize in Swagger and you will be able to perform test calls against the API directly from Swagger.
If you need to make changes to the specification, this can be done via the Swagger.json file.
Tool for developing UI components in isolation
Check here https://storybook.js.org/
AWS is used for uploading files on a AWS S3 bucket. There is a user on the AWS that has AmazonS3FullAccess
. There is not a AWS root key, but ONLY a key and a secret key for the AWS user.
If you need the key and secret to put into the .env file, write to the project manager of the project.
REMEMBER, this key should be kept super secret!!! NEVER add this to any PR!!
To make a new test, add a COMPONENT_NAME.test.js
to a component. See fx the Home
component to get an example of a simple test.
To run all test, write this command:
npm run test
To run the tests when you change a test file, run:
npm run test:watch
We created a small hook wrapper the fetch
API to abstract away the authorization headers.
It also has some other bells and whistles to make data fetching simpler such as:
Let's say I have a component which needs to fetch some data, this is how you could use it.
function App() {
const { response, loading, error } = useFetch(
'[SOME URL HERE TO AN API ENDPOINT]'
{} // here you can pass other options just like usual with the fetch API
);
const renderLoading = () => loading && <p>Loading...</p>;
const renderError = () => error && <p>Something went wrong...</p>;
const renderData = () => response && <p>{response.title}</p>;
return (
<div className="App">
<h1>I want to loading some data</h1>
{renderLoading()}
{renderError()}
{renderData()}
</div>
);
}
checkout the hook code here: useFetch
First clone the repo on your local machine using a terminal or a git client.
If you get this error: Error: ENOENT: no such file or directory, scandir
Then try and run this script: npm rebuild node-sass
To ensure we all code the same way, we are using linting in this project! We use prettier to do the linting for us. To Use the linting in this project, set your code editor up with the .prettierrc.js
files.
In Visual Studio code, go to file -> Preferences -> settings -> Search for prettier: config path
-> In the input write .prettierrc.js
This project is licensed under the MIT License - see the LICENSE.md file for details.