resource name:
handling errors with hooks

resource link:

• link here

Describe the bug / point of concern
This isn't so much of a bug as it is a needed fix. We're formatting our asyc lifecycle callbacks in a way that throws warnings in the console. We should follow the steps outlined in the warnings to eliminate them.

** Description **
We'll need a Header component for the top of the app. It should have a title, search bar, and link to our FAQ.

** Planning **
Refer to the Miro for specific docs.

** Description **
We should be able to visit the site from any browser, have everything work correctly, and install it on a phone. It should automatically use HTTPS instead of HTTP. We can try this through Vercel but if it does not use HTTPS we should try a different method.

Describe the bug / point of concern
On iOS mobile devices the FAQ link element is not visible. Searching for the term 'FAQ' identifies an element that appears to be in the correct place, but it is not visible nor clickable. The app works exactly as expected on non-iOS mobile devices. iOS users can type in the /faq url themselves to visit the FAQ page and it loads normally.

Location / Steps To Reproduce
Steps to reproduce the behavior:

1. Go to breath-ez.vercel.app on any iOS device.
2. Notice the lack of an FAQ link in the upper right corner.
3. Compare this with an Android phone or desktop browser.

As a User, when I open the app I want to be able to search for a location so that I can navigate to a page with detailed information about the air quality in that location.

Acceptance Criteria:
-Navigate to the homepage.
-Input(/select) a specific location using our search bar.
-The app should route to a new page displaying air quality for that same location.

** Description **

What does this addition do? What problems does it solve?

• adds routes that let us move between the faq and home paths via links
  ** Planning **

Is there a specific plan for how to implement this? What needs to change?

• use router
• implement two routes
  • one will be for faq path
  • one will be for / path
• these will be attached to links
  • both links will be rendered conditionally by Header
    ** Related Features **

What features and user stories rely on this addition?
#5

** Description **
We need an FAQ component that includes copy explaining how our rating system works and how air quality is evaluated.

** Planning **
Refer to the Miro for specific docs.

As a User when I visit a location details page, I want to see statics on current air quality, past trends, and future predictions. These statistics should be accessible to me even if I don't understand how air quality is measured.

Acceptance Criteria:
-Navigate to a location's detail page (either using a url, or the search bar)
-It should display a rating of air quality, that's accessible to the average person.
-It should display more detailed/specific pollution information for the past 48 hours.
-It should display predictions for future pollution levels.

** Description **
The site should have fallback javascript for when it's not connected to the internet. There are several online guides on how to set this up and we should likely follow one of those closely and then deviate as needed. The metric for success is passing the chrome Lighthouse audit.

** Description **
We should establish some initial architecture so that we can build out features without many merge conflicts.

** Planning **
We haven't agreed on anything but a super basic modular react tree should work.

** Related Features **
Literally all of them.

** Description **
This is a placeholder issue for the second major iteration of our app. Once we're satisfied with our app as a browser app we should plan how to convert it to a PWA and open issues to itemize that process.

As a User,

When I click on the FAQ link,

I want to see and be able to click on the different information section.

So that I can understand what the information given to me means.

** Description **
The site should be fully accessible. There are three ways we should test this:

1. We should get a high score on Lighthouse's accessibility audit- ideally a 100.
2. We should navigate the site with a screen reader the tab key and make sure it works.
3. We should explore color-blindness simulations and make sure our contrast ratios hold up.

Describe the bug / point of concern
Some valid icon codes we get from the API have no corresponding icon in our assets.

Location / Steps To Reproduce
Steps to reproduce the behavior:

1. Go to the app
2. Open dev tools
3. Load data for a city
4. Open up the hooks in app and change ic to 04n
5. There should be no weather icon now.
   Expected behavior
   Every valid code should have a corresponding icon

Additional context
The issue is that the documentation doesn't give us duplicate icons even though some codes apply to the same icon. We just need to create these duplicates in ourselves.

resource name:

• Stand-up schedule

resource link:
link

resource name:

• our Miro board

resource link:
link to Miro board

** Description **
We need to build out or App component including whatever methods might live there, and determine the logic of it's render method.

** Planning **
Refer to the Miro for specific docs.

• acceptance criteria should be the mark for when a user story is complete
• it needs to be specific and measurable

resource name:

• stand-up with Scott/day 1

resource body:

where to go

• polished mvp over new features
• may be worth doing together for naming
• styling separately recommended

nail down pwa

• start mobile first

hooks

• start without worrying about them
  • refactor class to stateless hook component
  • possibility

** Description **
We should have a loading screen while the user is awaiting api calls.

** Planning **
I think the best move is to use react promise tracker and some kind of react spinner dependency (of which there are many).

resource name:
AirVisual API documentation
resource link:
main link
more detailed link

resource name:

• DTR

resource link:

• link to DTR

** Description **
We need the DOM to update and inform the user of any 404 or 500 errors. These updates should be informative so that the user can tell exactly what's gone wrong and how they might fix it.

** Planning **
Refer to the Miro for specific docs.

Describe the bug / point of concern
When the user visits the FAQ page the title/logo shifts slightly because of changing text in the header.

Location / Steps To Reproduce
Steps to reproduce the behavior:

1. Go to the app
2. Click on FAQ
3. Watch the elements in the header shift around.
4. Go back and watch it happen it again.

Expected behavior
The title/logo should stay where it is and not move.

** Description **
THIS IS A STRETCH GOAL. We should make sure we complete everything else , or at least are confident about our MVP first.

We should use location services to allow the landing page to automatically display information for the closest city. If we begin work on this issue we should first design an appropriate user story and tests, and then build the feature to pass those metrics.

Describe the bug / point of concern
We're failing an option Lighthouse check that indicates whether the app adjusts dynamically to the viewport width. We have code that should handle this but it either isn't working, or isn't working properly with Lighthouse.

Location / Steps To Reproduce
Steps to reproduce the behavior:

1. Go to the App
2. Open dev tools
3. Run the lighthouse PWA audit
4. Scroll down to the viewport width test and see that it's grey (not red, but not green)

Expected behavior
Ideally this test should pass and give us a green check.

** Description **
We should design a version of the site that looks good on a desktop browser. There's a considerable amount of creative freedom here. This includes responsiveness, but also a fair bit of redesigning to make use of more space.

As a User when I click the FAQ navigation button at the top of the app, I want to visit a page that explains how the app works, and how we rate air quality, so that I can better understand the information that the app is giving me.

Description

What does this addition do? What problems does it solve?

• This addition gives us a solid README template to follow.

Planning

Is there a specific plan for how to implement this? What needs to change?

• We can use this as a basis, filling in our own info.

resource name:
rubric page
resource link:
page

** Description **
We need to build a series of Cypress tests that can navigate our app and asses it. This should include stubbed API calls so that we don't rely on the server. This needs to include unit and integration tests.

** Planning **
No planning exists for this yet. We should wait until everything else about the site is somewhat viable before we begin writing tests.

resource name:

• using Github Actions to movie Issues to project boards automatically

resource link:

• link

** Description **
We need to determine where we'll be communicating with API and where the function calls will live. The functions should likely be in their own file which will then be imported into App.js.

** Planning **
Refer to the Miro for specific docs.