You can find the deployed project at lyfe-logger-fe.herokuapp.com.
Web PT 11 Labs Group
Ana Carrillo, TL | Jackie Atwood | Wade Coplen | Janessa Garrow |
---|---|---|---|
David Moates | |||
Web PT 7 Labs Group
Carl Stanley | Sagdi Formanov | Joseph Hayden | Karen Yearwood |
---|---|---|---|
Eric Wise | Denvinn Magsino | Dave Vazquez | |
Organize all the things about life that are irregular. The things you forget to do. Change your oil, rotate your tires, replace your AC air filter. Home, auto, other maintenance tasks. Log events, later searchable so you can remember when/where/what you did.
- Access a calendar with events displayed
- Ability to create events with various information. When, where, category (work,home life, recreation).
- Search feature so you can remember when/where/what you did.
- Functional user dashboard to manage events.
- React, using `create-react-app` as a framework.
- Context API for state management.
- Theme UI and Emotion for styling
Front end deployed to Heroku
Back end deployed to Heroku
Clone this project and run npm install
at the root of this project in your terminal.
Run npm run startDev
to spin up a local development server. The start
script in the package.json
is for Heroku to properly build the app.
This app uses React testing library. To run your tests, use the command npm test
. Use the command npm test -- --coverage --watchAll=false
to run a test coverage report.
A more user-friendly way to read the test coverage report is to navigate to coverage/lcov-report/index.html
and open that html file in your browser. Then you can click through the different folders and files to see highlights of parts of your code that might still be missing tests.
All test files can be found within a __tests__
folder within the directory the original file is located. For example, for the file src/components/dashboard/Dashboard.js
, the Dashboard.test.js
file is located at src/components/dashboard/__tests__/Dasboard.test.js
.
Any component that accesses any styling from the theme
must be wrapped in a ThemeProvider
. A utility function was created specifically for tests in tests/themeProviderTestsUtil.js
. In a test file where you would normally import render
from @testing-library/react
import it from this utility function instead. For your convenience, in any file where you are importing from this utility function, you can also import any method available from @testing-library/react
as they've all been re-exported in that file. render
takes the following parameters:
ui
-- **required, the component you want to test- renderOptions (an object) -- **optional, you can pass in a mock Context store or initial state here
For any component that needs to be wrapped in a Router
, a utility function was created at tests/routerTestsUtil.js
. In a test file where you would normally import renderWithRouter
from @testing-library/react
import it from this utility function instead. renderWithRouter
takes in the following parameters:
Ui
-- **required, the component you want to test- {path, route, history} -- **optional,
path
androute
default to/
andhistory
defaults tocreateMemoryHistory({ initialEntries: [route] })
(createMemoryHistory
is imported fromhistory
) - renderOptions (an object) -- **optional, you can pass in a mock Context store or initial state here
Create a .env.development
and .env.production
file so you don't have to hard code any environment variables anywhere. Below is a list of environment variable names you will need:
- `BASE_HOST` -- the base URL for the backend server
- for development using your local server, set this to `http://localhost:5000` or whatever port your local backend runs on
- for production, set this to the deployed URL of the backend server
This project uses Theme UI, with Emotion used for some Styled Components (Theme UI uses Emotion under the hood, which is why we opted for Emotion vs. Styled Components). The theme
styles for this project are located at src/theme/theme.js
In any component where you want to have any styling from the theme
file needs to have the following imported at the very top of the file (including the comment):
/** @jsx jsx */
import { jsx } from 'theme-ui';
Import any Theme UI components from @theme-ui/components
. For example:
import { Card } from '@theme-ui/components';
A list of available components can be found in the Theme UI docs. To override any of the default styling for your own theme, you must create a variant inside of your theme
file.
For example, according to the docs, the Card
component is found in the cards
variant group. This means that within your theme
object, you can create a cards
key, whose value is an object. Within that cards
object, the default "variant" for a Card
is called primary
. In order to override Theme UI's default stylings for that basic, default Card
, you must create a primary
key inside of your cards
object and provide your stylings there.
See the official docs or a write-up by Janessa Garrow on some of the basics of Theme UI.
This project also uses Framer Motion for some animations, particularly for sliding the task cards in the mobile view. The docs are a great place to go. This Egghead video compilation is a nice intro, as well.
As per Lambda's Labs Engineering Standards, we have included eslint
(with the default rules) to help keep the codebase cleaner and more consistent across files. To change any of the linter rules, update the .eslintrc.js
file at the root of the project.
Likewise, to make any changes to the Prettier rules for this project, update the .prettierrc.js
file at the root of the project.
Husky is a library that can help prevent "bad" commits from being committed to your branch. In the package.json
at the root of the project, you can configure the husky hooks to run certain commands when you want. See the husky docs for more info. In this project, we have configured husky so that on pre-commit, it will run our lint-staged
rules. "Pre-commit" means that when you stage your changes and run a git commit
command, husky will actually run your pre-commit
git hook before it actually commits your changes.
Lint-staged is a library that will run your linter against staged files. This can allow you to check if any of your changes break any linting rules. If they do, lint-staged steps in and the commit will not be run. See the lint-staged docs here. For this project, we configured lint-staged in the package.json
so that our eslint
rules will be run against all .js
files and any of the following filetypes -- js|jsx|json|yml|yaml|css|less|scss|ts|tsx|md|graphql|mdx
-- will be run through our prettier
rules and automatically changed to match the rules in the .prettierrc.js
file and then being re-staged.
When we use husky and lint-staged together, husky will make sure the linter and prettier get run before every single commit. This will help catch any errors and fix syntax inconsistencies to help streamline the process of writing more consistent code as a team working on the same repo.
Docs: eslint prettier husky lint-staged
When creating a component that takes in props, eslint requires that you declare what the expected type is of each prop. For any component taking in props, you will need to import the following at the top of the file:
import PropTypes from 'prop-types';
Then you can use PropTypes
to specify the types for your props. For example, the Task
component takes in a task
prop. We can declare what type we expect task
to be like so (take note of the differences in capitalization -- it matters!):
// ComponentName.propTypes
Task.propTypes = {
// nameOfProp: PropTypes.expectedTypeHere
task: PropTypes.object,
};
See the docs for more info.
If you are having an issue with the existing project code, please submit a bug report under the following guidelines:
- Check first to see if your issue has already been reported.
- Check to see if the issue has recently been fixed by attempting to reproduce the issue using the latest master branch in the repository.
- Create a live example of the problem.
- Submit a detailed bug report including your environment & browser, steps to reproduce the issue, actual and expected outcomes, where you believe the issue is originating from, and any potential solutions you have considered.
We would love to hear from you about new features which would improve this app and further the aims of our project. Please provide as much detail and information as possible to show us why you think your new feature should be implemented.
If you have developed a patch, bug fix, or new feature that would improve this app, please submit a pull request. It is best to communicate your ideas with the developers first before investing a great deal of time into a pull request to ensure that it will mesh smoothly with the project.
Remember that this project is licensed under the MIT license, and by submitting a pull request, you agree that your work will be, too.
- Ensure any install or build dependencies are removed before the end of the layer when doing a build.
- Update the README.md with details of changes to the interface, including new plist variables, exposed ports, useful file locations and container parameters.
- Ensure that your code conforms to our existing code conventions and test coverage.
- Include the relevant issue number, if applicable.
- You may merge the Pull Request in once you have the sign-off of two other developers, or if you do not have permission to do that, you may request the second reviewer to merge it for you.
These contribution guidelines have been adapted from this good-Contributing.md-template.
See Backend Documentation for details on the backend of our project.