Project 2: React

Overview

Let's kick it up a notch and build a modular and modern front end application using React!

Like with project one, the Unit 2 project is a chance to be creative and build something you should be proud of. You will be working individually for this project, but we'll be guiding you along the process and helping as you go.

You must submit your idea to your squad leader by noon EST Monday.

Show us what you've got!

Requirements

Your website must:

• Be a working, interactive, React application.

• Include data from a third-party API.

  • Pull data into the application using an API
    List of Public APIs
    More APIs
    Instructor Recommended APIs
  • TRY OUT your API in the browser by making an fetch request before you get too emotionally invested in it, to make sure it works the way you think it does...YOU ARE REQUIRED TO SHOW US YOU CAN RECEIVE THE DATA FOR YOUR PROPOSAL

• Use React Router.

• Have at least 6 separate components, using a readable file structure.

• Be built using Create React App.

• Be styled with CSS.

• Use Flexbox or CSS Grid for layouts.

• Use functional components and class components appropriately.

• Be deployed via Netlify.

• Optionally, you may incorporate a component library to design your app with approval, or use Next.js or Gatsby instead of React Router and Create React App

Your code must:

• Be properly indented.
• Be written with semantic, camelCase JavaScript variable names.
• Be written with kebab-case (dashes) CSS class names.
• Contain no console.log() or commented out code in final version.
• Use only React for DOM manipulation.
• No pre-loaded create-react-app files or code.

Necessary Deliverables

A README with the following:

Refer to the project worksheet file in this repo for structuring your README.

For the proposal:

• A collection of wireframes - hand-drawn or digitally created - outlining the important pages of your site, as well as the critical states of your project, drawing a component hierarchy would be a great way to indicate which components need state and which components need props.
• A proposal including:
  • A description of the project you'll be building with the objective described in non-technical language.
  • An explanation of the major problems you plan to face while implementing this app.
  • An explanation of how you foresee yourself solving the aforementioned problems.
  • A visual of your component hierarchy.
  • A link to the API you plan to use.
  • A section clearly defining MVP and POST MVP.
  • If you plan on incorporating a component library, include a link in your proposal.

For the project:

• A git repository hosted on GitHub, with a link to your hosted project, and frequent commits dating back to the very beginning of the project (YOUR APP SHOULD BE LOCATED IN A SEPARATE STANDING REPO. DO NOT build your app in this repository. YOU MUST initiate a new repo on your GitHub account.)

---

Tips

• Commit early, commit often. Don't be afraid to break something because you can always go back in time to a previous version.

Planning

1. Watch this video on the Minimum Viable Product

2. Begin with the end in mind. Spend a dedicated block of time to planning with wireframes and user stories so you don't waste time building things you don't need.

3. Write pseudocode before you write actual code. Thinking through the logic of something helps streamline your process.

4. User stories define what a specific type of user wants to accomplish with your application. It's tempting to just use your list of user stories as a todo list, but try to avoid this. If you keep your user stories small and focused on what a user cares about being able to do. This will help you prioritize your tasks and which features to build first.

Definition of User Stories

Building Out from your Plan

After planning your app:

1. Create your React architecture
2. Build your Components
3. Decided on your CSS styling.
4. Add new features!

Getting Unstuck

• Don't hesitate to write messy code to solve short-term problems—Refactor later
• Read the docs for whatever technologies you use. The docs often include a tutorial that can help you get started, and learning to read documentation is crucial to your success as a developer.

Asking For Help

In-person Support

Each student will be given 5 (five) tokens, redeemable at any time during regular class and Study Hall time (not including evening Office hours), for 20 minutes with an instructor. Tokens cannot be transferred between students - there is no black market for tokens.

Instructors will not be holding open office hours during project week. This is to give you the opportunity to solve issues and errors you run in to on your own and with your classmates. Dan, however, will still hold his office hours as planned.

An instructor will be assigned to each team and wil check in with your team every morning for about 15 minutes. The purpose of these check-ins is not to discuss technical questions, but to answer questions about workflow and get a status checkin.

Maximizing Effectiveness of Support Sessions

Prior to using one of your tokens, we strongly recommend that you file an issue on this repository in order to both provide the instructor with a point of reference regarding your code and the issue you are having. This will enable us to give you more effective guidance.

When you submit an issue please include the following:

1. A code snippet
2. A precise and specific description of your issue
3. What error you got
4. What you already tried to resolve your error and the result of those attempts

Check here for details on this process.

We also strongly recommend using Slack to get help from your classmates. Chances are you all will be running into similar problems.

A Note on Plagiarism

Take a moment to re-familiarize yourself with the plagiarism policy, specifically on using work you find online and on work you do with other students.