Hang In There - Pair

Helpful Hints

- Repo Settings » Pages » Select the main branch as your Source branch » Save. Then, wait up to an hour, hit refresh, and your deployed link should appear at the top of the screen.  

- If you don't want to wait, your GH pages URL will follow this format: "https://username.github.io/hang-in-there/". Replace "username" with the repo owner's GH username and "hang-in-there" with your repo's name (if different). The URL will not work right away - that's ok! Add it to the Project Submission form anyway. 

Refactoring as You Go

Between each iteration, take some time to look at the code you’ve written and make any changes that might improve the readability of your code. Refactoring as you go can help ensure that everyone understands the code you’ve written so far AND make it easier to build on top of that code.

Here are some ideas of what to look for:

• Is our indentation and spacing consistent?
• Are our variable names descriptive of the values they hold? Do they follow common convention (i.e. arrays are plural, etc)?
• Are our function names descriptive of what the function does? Are they named with present tense verbs?
• Are any of our functions too big or doing too many things? Should we break any of them up?
• Is any of our JS code too repetitive? Could we make any reusable functions with parameters and arguments?

Remember - shorter code isn’t always better!

Set Up + Day 1 Deliverables

To begin, choose ONE partner to do the following:

1. Fork the repository found here: https://github.com/turingschool-examples/hang-in-there-boilerplate/.
2. Clone down your new, forked repo. While cloning, name it what you want your project to be named, should not include “boilerplate”. git clone <url> <newNameYouWantItToHave>
3. cd into the repository
4. Open it in your text editor
5. View the project in the browser by running open index.html in your terminal
6. Add all project partners and your assigned instructor as collaborators on the repository

Then, as a team:

• Explore the repository to see what’s going on in the code. Look at each file.
  • What pieces of code might you use to complete iterations, and what pieces will you have to create?
• All of your JavaScript will be written in main.js - you will not need to change any other files.

By EOD on Kick Off Day:

• As a team, read the entire project spec and rubric
• As a team, complete the Norming Form
• Complete this project submission form to ensure your project manager has the necessary links. (Note: See Helpful Hints for help with deploying!)
• Add all teammates and your assigned instructor as collaborators to your forked repository

Iteration 0 - Main Page

• When the page loads, we should see a poster with a randomly selected image, title, and quote
• Every time the user clicks the Show Random Poster button, a new random poster is displayed.

Iteration 1 - Switching Views

Form view:

Saved posters view:

• When a user clicks the “Make Your Own Poster” button, we should see the form, and the main poster should be hidden
• When a user clicks the “View Saved Posters” button, we should see the saved posters area, and the main poster should be hidden
• When a user clicks the “Nevermind, take me back!” or “Back to Main” buttons, we should only see the main poster section
• In summary: Be able to switch between the three views (main poster, form, and saved posters) on the correct button clicks

Hint: go check out the HTML and CSS files to see how the form and saved posters sections are being hidden in the first place

Iteration 2 - Creating a New Poster

Result after clicking Show My Poster button:

• On the new poster form view, users should be able to fill out the three input fields and then hit the Show My Poster button
• When the Show My Poster button is clicked, several things will happen:
  • Use the values from the inputs to create a new, unique poster object (part of your data model)
  • Save the submitted data into the respective arrays (image URL into the images array, etc - all part of your data model) so that future random posters can use the user-created data
  • Change back to the main poster view (hiding the form view again)
  • Use the new, unique poster object (part of your data model) to display the newly created poster image, title, and quote in the main view on the DOM

Iteration 3 - Saving & Viewing Posters

• When a user clicks the “Save This Poster” button, the current main poster will be added to the savedPosters array.
• If a user clicks the “Save This Poster” more than once on a single poster, it will still only be saved once (no duplicates)
• When a user clicks the “Show Saved Posters” button, we should see the saved posters section
• All the posters in the savedPosters array should be displayed in the saved posters grid section

Iteration 4 - Deleting Saved Posters

• From the saved posters view, if a user double clicks a saved poster, it will be deleted
  • HTML onclick attributes should not be used in any HTML code - all functionality should be through JavaScript.

Optional Extensions

Here’s a list of possible extensions to implement - but ONLY IF your team has completed all the previous iterations AND have cleaned up your code to make it DRYer and more readable.

You are welcome to add your own extensions. Be sure they are thoughtful in terms of UX/UI, and that they do not break any prior functionality.

• Implement data validation and error handling into the form (disable button, provide error messages if data entered is not correct, etc)
• In the main poster view, allow users to click each piece of the poster (image, title, quote) to update just that piece with another random item from the appropriate array
• When a user single clicks a saved poster, create a modal to view it larger
• Allow users to drag and drop saved posters into whatever order they want them to appear

JavaScript

💫ON TRACK💫 can look like:

• JS is formatted according to the Turing JS style guide
• The main JS file is organized thoughtfully (DOM variables together, event listeners together, functions together)
• Variable and function naming is meaningful, readable, and follow convention. (Arrays are plural, functions begin with present-tense verb, etc.)
• Functions are DRY (Don’t Repeat Yourself) and demonstrate SRP (Single Responsibility Principle)
• Global variables are limited to only those that are necessary.
• Only semantic/organizational comments remain in file (if any). No console logs remain in any files.

✨WOW✨ can look like:

• Team keeps the data model logic separate from the DOM logic
• Functions make use of arguments and parameters to be dynamic and reusable where possible without overengineering

Workflow & Professional Habits

💫ON TRACK💫 can look like:

• The team’s norming document is taken seriously, with thoughtful reflections from all team members regarding their skills, learning goals, work styles, etc.
• The work is distributed equitably; Commit/code contributions (viewable under Insights tab) are roughly even for each team member.
• Commits are made regularly to describe small chunks of working code. Commit messages are descriptive, concise, and consistent across all team members.
• The team keeps the main branch clean by using branches for new, unreviewed code. No one pushes code directly to the main branch.
• PRs have clear, thorough descriptions, such that a new person joining the codebase can clearly understand the proposed changes and evolution of the codebase.
• The README template is filled out thoughtfully and completely.

✨WOW✨ can look like:

• Team uses a PR template.
• Meaningful decisions are documented through code reviews. Suggested/requested edits are made before merging.

Reading Code

💫ON TRACK💫 can look like:

• The team takes time to thoroughly understand the provided code
• Provided code is used effectively (the provided createPoster function, the provided assets, the provided HTML & CSS)
  • The team does not directly edit the HTML or CSS file
  • The team does not ignore provided styling
  • No code is added that makes the provided code redundant

✨WOW✨ can look like:

• Creating and sharing a document (with your PM) for the team’s observations of and questions about the existing code

Functionality

Functionality is the least important piece of the rubric. It’s included because it is another benchmark to gauge proficiency (for example, we can’t grade your JS if there isn’t enough of it written!). However, you should not pursue functionality at the expense of code quality or the learning/growth of all team members.

This means, we DO NOT want to see:

• Code that completes iterations but is sloppy
• One or both team members do not understand every single line of code
• One or both team members skips the problem solving process (pseudocoding, talking out the problem, articulating, planning) in the pursuit of completing functionality

Well-refactored, thoughtful code is better than sloppy extra features.

💫ON TRACK💫 can look like:

• All of the expectations of iterations 0-4 are complete without bugs

✨WOW✨ can look like:

• All of the expectations of iterations 0-4 and an extension are complete without bugs