Rancid Tomatillos

This project is definitely not Rotten Tomatoes. Nor is it Netflix. Nor is it IMDB. It’s R A N C I D T O M A T I L L O S. Very different!

Learning Goals

• Gain competency with React fundamentals
• Test React components & asynchronous JS
• Practice refactoring
• Create a multi-page UX using Router

Iterations

We’ve broken this project down into iterations. Please be sure to read them closely with your project partner!

Iteration 0 - Initial Deliverables

Turn in all deliverables via this google sheet.

By the end of the day, Day 1:

• The link to your repo (hint: use Create-React-App to start your project!)
• The link to your DTR
• The link to your Project Board with at least a few user stories entered

By the end of the day, Day 2:

• A link to 2-3 pieces of design inspiration that you will aim to mimic
• A wireframe of your app - this can include sketches of your user interface, or a link to your Canva, InVision, etc.
• An initial plan for your component architecture. You should answer the following questions:
  • What components do you envision needing?
  • Where will data be stored?
  • How will information be passed around?

Iteration 1 - Displaying movies

For this first iteration, we will use mock data to display the movies (we will later refactor our project to consume an API). The purpose of using mock data instead of querying the actual API is to allow us to focus purely on React for now.

In your project repo, create a new file in the src folder. Copy in the data found in this gist.

For now, you will import this information into your App.js file and use this as your source of information!

import movieData from 'put your filepath here'

User Story

• As a user, when I visit the app, all movies should be displayed

Suggested completion date

• End of Day 2

Iteration 2 - Displaying an individual movie

For the second iteration, we’ll use conditional rendering to show a single movie’s details.

In the future, when we use the actual API to get individual movie details, the information will change. For now, you can use some default “dummy” data, and know that it will eventually change and be dynamic:

{"movie": {id: 1, title: "Fake Movie Title", poster_path: "https://image.tmdb.org/t/p/original//7G2VvG1lU8q758uOqU6z2Ds0qpA.jpg", backdrop_path: "https://image.tmdb.org/t/p/original//oazPqs1z78LcIOFslbKtJLGlueo.jpg", release_date: "2019-12-04", overview: "Some overview that is full of buzzwords to attempt to entice you to watch this movie! Explosions! Drama! True love! Robots! A cute dog!", average_rating: 6, genres: ["Drama"], budget:63000000, revenue:100853753, runtime:139, tagline: "It's a movie!" }}

OR: You can also simply use the existing movie data that you already have access to (“id”, “title”, “poster_path”, “backdrop_path”, “release_date”), knowing that eventually you will add more information (“overview”, “genres”, “budget”, “revenue”, “runtime”, and “tagline”).

User Story

• As a user, I can click a movie, and see that movie’s details
  • When a movie’s details are displayed, none of the other movies will be visible; it should just be that movie’s details (header/footer/etc can still be visible, of course!)
  • When a movie’s details are displayed, the user should have a way to return to the main view of all movies

Suggested completion date

• End of Week 1

Iteration 3 - Network Requests & Async JS

For the third iteration, we’ll refactor our application to:

• use actual data from the database (information is below) instead of our mocked movieData file.
• include type checking with PropTypes

Also, please complete the First Weekend Deliverables (found below)

User Story

• When the server returns a 500 error, the user will see proper error handling
• No other user-facing features required
• We’re mostly refactoring in this iteration!

Suggested completion date

• End of first weekend

Suggested testing progress by end of iteration

• Project board has been updated so functionality is described as user stories
• Each user story includes thorough acceptance criteria
• All components that receive props utilize type checking with PropTypes

FIRST WEEKEND DELIVERABLES

By the time class begins in Week 2, these items should be completed:

1. Iterations 0-3
2. Project board has been updated so functionality is described as user stories
3. Each user story includes thorough acceptance criteria
4. Instructors have been DM’d a link to one PR (see below)

Iteration 4 - Refactoring with Router, Testing with Cypress

In the fourth iteration, we will be testing with Cypress, and refactoring our application to use Router instead of conditional rendering to change the view!

For Cypress, add the following tests to start:

• As a user, when I load the application, I can see the title of the application
• As a user, when I load the application, I can see a collection of movies.
• As a user, when I click on a movie, I’m shown additional details about that movie
• Any other user stories you might have already should also be tested.

So far the application has worked like a single page application. We have different views that are conditionally rendered, but we have to control the logic for when to render certain things. Furthermore, the URL never changes.

To crete a better UX, we’re going to be using React Router to conditionally render our views based on the URL.

This iteration is all about refactoring. Use the table below to add in appropriate routes.

As you refactor, continue to rely on your test suite to ensure that no functionality is being lost/destroyed as you add in Router!

Look into the Cypress assertions which allow us to view our current URL pathname and add those into your tests!

User Story

• When a user clicks on a movie and the details page is rendered, the URL updates to reflect that movie’s unique ID as well
• The user can click the browser forward & back arrows to navigate

Suggested completion date

• End of Thursday in Week 2

Suggested testing progress by end of iteration

• Application views and user flows are fully tested
• Asynchronous functions are stubbed

Iteration 5 - Choose your own adventure

The final days (last weekend and beginning of Week 3) of this project are designed to give you agency over your learning goals! As a team, consider your learning goals:

• What will best serve your team- and individual- learning goals?
• What areas/concepts are still unclear?
• What areas/concepts fit in with your professional goals?

Decide as a team what to focus on and complete the Week 2 Deliverables (found below), choosing a new feature to implement or a thorough rubric-based refactor.

PROJECT DUE DATE: 6pm Saturday of Week 2

The project is due Saturday to give you space to breathe before diving into the code for your stretch project.

If you have created a back-end repo and/or deployed your front-end, then add links to the deployed app or additional repos in your front-end README.

Minimum Collaboration and Professionalism Expectations

• Team holds daily standups throughout project.
• Commits are atomic and frequent, effectively documenting the evolution/progression of the application. There is no more than a 10% disparity in project contributions between teammates.
• A project board is utilized (and updated throughout the project) with Github issues and labels.
• Team members use branches/PRs and do consistent, thorough, meaningful code reviews of PRs, which prompt updates and changes made to that PR before merging
• The README is formatted well and at a minimum contains:
  • Overview of project and goals
  • Overview of technologies used, challenges, wins, and any other reflections
  • Screenshots/gifs of your app
  • Links to contributors’ GitHub profiles and any applicable repos/deployed sites
• When the project is run locally, the terminal shows no errors or warnings
• Team collaborates effectively to accomplish the shared goal. Team productively and professionally works through challenges and conflicts to ensure all team members are able to be heard and contribute throughout the project.
  • Instructors are available to offer support and guidance but conversations around what is and what is not working are expected to be led by the team members themselves.

Rubric

For the rubric sections below, you will be scored as Wow, Yes or Not Yet depending on whether you have demonstrated competency in that area. Each section lists examples of what types of things we may be looking for as demonstrations of competency. Just as there are many ways to approach code, there are many many ways to demonstrate competency. These are just some examples.

In addition to any WOW examples listed below, you can strive for a WOW by demonstrating not just competency, but excellence and thoroughness across the rubric sections.

Collaboration and Professionalism

• See “Minimum Collaboration and Professionalism Expectations” above.
• While this is not a scored rubric section, every team member is expected to fully participate, contribute, communicate and collaborate with the team throughout the entirety of this project. Failure to do so can result in an individual failing the project, even if the group/project is otherwise passing.