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.

We’ll also add some 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 new 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 with 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?

Here is a list of concepts (including some push-yourself learning goals):

• React
• Router
• Asynchronous JS
• Responsive Design
  • use media queries and other tools to allow your application to resize to varying screen sizes
• Testing
  • Ensure that every view is tested (including all possible renders when dealing with conditional rendering)
  • Ensure that all possible user flows are tested (happy and sad paths)
  • Ensure all asynchronous JS is properly stubbed
• Express (server-side JavaScript)
• Deployment

Decide as a team what to focus on. Also, please complete the Week 2 Deliverables (found below)

Once you have decided on the area to continue learning, decide on a new feature or refactor.

Suggested completion date

• All code for the project should be completed by end of Sunday of Week 3 (so you can leave Monday for polishing the project and finishing the README, not building out features!)

PROJECT DUE DATE: 9pm Monday of Week 3

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.

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.

React Architecture

On track can look like:

• A consistent, modular file structure is used
• Create reusable and modular functional components by incorporating props and considering component composition
• hooks are implemented to manage and update state
• Pass functions as props to effectively organize the application
• return statements are as readable as possible, only communicating what will be displayed
• Frontend state matches the backend data
• Props are protected via Proptypes or type-checking
• Only necessary data is passed as props
• state is pure and immutable
• Code is DRY, reusable, and empathetic

WOW can look like:

• Deploy your React app (to GitHub Pages or similar service)
• Application handles errors if the server is down or if a fetch call fails and displays information to the user
• Application shows loading state
• Only necessary data is used in the application when retrieving data from a server

Testing

On track can look like:

• All application views are tested
• All user flows are tested
• Happy path async functionality is stubbed and tested

Wow Option: Sad path async functionality is tested

Routing

On track can look like:

• Application uses Router to display appropriate components based on URL
• The user has access to previous routes via the back button
• A 404 page handles unknown routes

Wow option: Code was refactored to remove unnecessary or old code artifacts

Project Professionalism

You will not receive a score for professionalism, but you should be meeting these expectations:

• Each group member contributes equitably to the project. Failure to participate can result in an individual failing the project, even if the project is otherwise passing
• README concisely communicates the team’s individual and joint learning goals, the evolution of the project, and team member reflections while using good formatting to enhance readability
• README links to all user GitHub profiles and any applicable repos/deployed sites
• README includes a gif of the application
• Git commits are atomic, with concise and precise descriptions of the change made
• PRs have full, consistent descriptions and are formatted using a PR template
• Team members do consistent, thorough, meaningful code reviews of PRs, which prompt updates and changes made to that PR before merging
• Evolution of the project (decisions made, etc) are fully and clearly documented in the git history and PRs
• When the project is run locally, the terminal shows no errors or warnings