This project will challenge you to use the technology you’ve become familiar with over the course of Mod 3, as well as force you to work inside some constraints. Everyone will be working with (at least) one API and one audience.
Choose an open API to work with where the data sounds interesting to you. A good place to start looking is this repo with a list of free/open APIs. Choose an API where you could make an application based on the data from the API. Do not choose an API that requires “OAuth or OAuth 2.0”, which is a more complicated authentication scheme. Also, be wary of APIs that have “CORS” value of “yes.”
APIs that require an
apikey are usually easy to deal with, and some APIs don’t require an
apikey. If the API you want to use relies on an API key, be sure to request on ASAP!
After you have an API that interests you, the next thing you need to do is choose an audience. You need to be specific with your audience. For instance, if you chose an API that served cat data, your audience should not just be “cat lovers”, it should be something more specific like “cat lovers who live in Alaska”. This will give you some constraints for the project to make it more unique and design decisions a little easier.
Once you’ve got your API and audience settled, start thinking about how you’re going to build something for this audience, using that API. Come up with a few different ideas.
Wireframing will be a major component of this project. The more time you spend intentionally thinking about what the layout of your application will look like, the better the final result will be.
There are a lot of different tools you can use for this, including just plain old pen and paper. Just make sure you really spend time thinking about the user interactions. For a good overview of how to effectively wireframe a project, check out this video.
Project Goals and Requirements
- Use the technology you’ve been working with over the course of the module to
demonstrate mastery of the following:
Work within constraints to deliver a unique product for your audience which helps them in some way. Your project must utilize your assigned API and technology, and must be built for your assigned audience.
- Your applications should have the following core functionality:
- Display the data from the API in a way that applies directly to your audience
- Ability for users to store/manipulate the data displayed in the application, such as favoriting or adding to a list
By noon of day 1, send your instructional project manager the plans for you API, specific audience, and a general overview of what the application will do. Have a backup API/audience ready just in case.
If you have wireframes ready to go, send those along too. You can send your wireframes to your project manager at any time to get feedback.
- 4 - All requirements from 3 are met. The application completes all iterations above and implements one or more of the extensions. And the evaluator has no recommendations for design changes.
- 3 - The application uses the above technologies to a professional level. The evaluator has minimal recommendations for refactoring or design changes.
- 2 - The application is in a usable state, but is missing part of one or more of the technologies outlined above. Evaluator has multiple recommendations for design changes.
- 1 - The application is missing multiple features outlined above. Developer did minimal to no CSS for this project.
- 4 - All requirements from 3 met, PropType functionality is complete, codebase has zero linter errors/warnings, and README contains screenshots of application. Project team uses a rebase workflow, taking advantage of GitHub issues to track work. Project shows a complete mastery of React architecture.
- 3 - PropType functionality is tried but missing for some components, the codebase has less than 5 linter errors, README has been updated with all group members. Project utilized wireframes from the outset. All git commits are atomic, made first to branches, and use descriptive and concise commit messages. Project demonstrates a fundamental understanding of React architecture.
- 2 - Project are substantially unused, README updates, wireframes, or has more than 5 linter errors. Project team makes large infrequent git commits. Project shows a basic understanding of React.
- 1 - PropTypes are substantially unused, README is incomplete, wireframes were not used, or more than 10 linter errors are present. Git history does not show evolution of project, with many large and inconsistent commits. Project shows little understanding of React and significant refactoring is required.
- 4 - All async functionality is tested, tests are passing and run efficiently (using mount only when appropriate). Unit tests for snapshots and methods cover not only happy paths but also sad paths. Evaluator has no recommendations for testing.
- 3 - Includes testing from levels 1 and 2, and a valid attempt to test asynchronous functionality has been made. Asynchronous tests cover happy paths as well as multiple sad paths.
- 2 - Nearly all unit tests are in place. Components are well tested with a diverse set of tests including but not limited to snapshot tests, event simulation tests, and tests on class methods (including
componentDidMount). No attempt to test async functionality was made.
- 1 - There is little or no evidence of testing in the application. There are some UI tests including snapshot tests, but major gaps in unit testing functionality.
- 4 - All requirements from 3 met, and always chooses the correct component for rendering, as well as the correct Route API. Application should account for undefined routes.
- 3 - Application uses React Router to display appropriate components based on URL.
- 2 - Application uses React Router, but does not display the appropriate components upon navigating.
- 1 - Application uses React Router, but does not render/use all routes.