User should be able to easily view their token at any time

AC:

• The add an item screen (the screen a user uses to add a new item to their list) looks something like the following (or equivalent, use your creativity!):

Possible item states are as follows:

• Need to buy soon (fewer than 7 days)
• Need to buy kind of soon (between 7 & 30 days)
• Need to buy not soon (more than 30 days)
• Inactive (when there’s only 1 purchase in the database or the purchase is really out of date [the time that has elapsed since the last purchase is 2x what was estimated])

AC:

• Items in the list are shown as visually distinct (e.g., with a different background color on the list item) according to how soon the item is expected to be bought again: Soon, Kind of soon, Not soon, Inactive
• Items should be sorted by the estimated number of days until next purchase
• Items with the same number of estimated days until next purchase should be sorted alphabetically
• Items in the different states should be described distinctly when read by a screen reader

AC:

• User is able to tap a checkbox or similar UI element to mark an item in the list as purchased
• Item should be shown as checked for 24 hours after the purchase is made (i.e. we assume the user does not need to buy the item again for at least 1 day)

This is 1 of 2 stories that should be completed in the first week to enable further development of the app.

AC:

• react-router-dom has been added as a project dependency
• Links are present and persistent at the bottom of the app: one for the “list” view, the other for the “add an item” view
• When one of the links is clicked, the browser URL updates to represent the current view and a matching view component is displayed
• Whichever view is selected, the corresponding link should display in bold text

Move all API calls to Firestore to one 'services' file.
Update function signatures (the order in which they accept arguments) to make them match and ensure that they're more predictable (e.g. item, token in the same order for all functions)

AC:

• The shopping list screen (the screen that lists all of the user’s purchases) looks something like the following (or equivalent, use your creativity!):

Create a reusable modal to replace all instances of window alerts and other default dialog windows.

Base the new modal off of the Delete Modal component, and refactor Delete Modal component to use the new modal template.

Also make new modal accessible - to discuss with EJ

AC:

• The welcome screen (the screen a user sees before they’ve created their list) looks something like the following (or equivalent, use your creativity!):

AC:

• Show an error message if the user tries to submit a new item that has the exact same name as an existing item
• Show an error message if the user tries to submit a new item that has the same name as an existing item, where capitalization has been normalized and punctuation has been removed
• The user’s original input should be what gets saved in the database

AC:

• The list view, when there are no items to display, should show a prompt (e.g., a button) for the user to add their first item

This is 1 of 2 stories that should be completed in the first week to enable further development of the app.

AC:

• The following have been added as project dependencies: firebase & react-firestore
• Make a change in the Firestore database and it shows up in the app
• Make a change in the app and it shows up in the Firestore database

Checked (disabled) items are completely skipped over on screen readers and tabbing for Chrome and Firefox. Safari reads them fine.

AC:

• When a purchase is recorded, the estimated number of days until the next purchase date should be calculated and recorded in the database

The script at /src/lib/estimates.js should be used to calculate the next estimated purchase interval.

Tokens can be shared with other users to allow them to co-manage a given list.

Joining an existing list consists of the following:

• User enters an existing token
• Save the token to localStorage
• Show the user the existing list

AC:

• When the user does not already have a token in localStorage, on the onboarding/home screen, a simple form is displayed that allows the user to enter a token
• Entering the token and hitting submit saves the token to localStorage, effectively giving them joint control of the list
• On submit, show an error if the token does not exist
• If they get an error message, allow them to try again or create a new list

User story: As a developer, I would like a database that will scale more fluidly as we add new features.

Acceptance criteria:

• All API requests (getting, updating, deleting) work as before
• Filtering the list works as before
• Ordering the list works as before

Pain points with current implementations:

• Too much nesting: We currently have to dig in three layers to get to an item's details.
• Querying is complex and doesn't use the methods that firestore recommends.
• Firebase docs scare us away from nesting, BUT it can be useful. We currently have objects with properties but we can do something else to make it easier to add and access those elements. All lists are not evil.

Resources:

• Advice on how to structure data from Firestore's docs
• Search what other folks are doing.

Notes:

• Suggestion: All lists are not evil, we could consider using a proper list here.
• Talk openly. Share openly about your ideas in Slack. Ask for thoughts!
• Firestore allows nested collections. Collection of lists with a subcollection that is the items of the list.

It’s possible our users may make an error when entering an item or may decide they won’t be buying a certain item again in the future. Let’s help them keep their lists tidy!

AC:

• User is able to delete an item from the shopping list
• Before deleting, prompt the user to confirm that they really want to delete the item to prevent accidental deletions
• Deletion should cause the associated record(s) in the database to be deleted

AC:

• The item detail screen (the screen a user sees when they tap on one of their items in the shopping list) looks something like the following (or equivalent, use your creativity!):

On list view, the Details button's aria label is rendering incorrectly. The aria label should read "Details for item name" as opposed to "[Object object]"

The current implementation of live region does not actually send changes to assistive technologies.

User should be able to return Home so they can change their token to another

AC:

• From the shopping list, user can tap to navigate to a detailed view of the item
• Detail view includes the following information:
  • Name of the item
  • Last purchased date
  • Estimated number of days until the next purchase
  • Number of times the item has been purchased
• When in the “item details” view, a back arrow should appear in the header that takes the user back to the “list” view

A shopping list item consists of the following data points:

• Name of item
• How soon are you likely to buy it again?
  • Soon (in the next 7 days)
  • Kind of soon (in the next 14 days)
  • Not soon (in the next 30 days)
• Last purchased date

AC:

• User is presented with a form that allows them to enter the name of the item and select how soon they anticipate needing to buy it again (Soon, Kind of Soon, Not Soon)
• When the user submits the form, the item is saved to the database, associated with the user’s token
• Along with the item name, an integer corresponding to the estimated number of days until next purchase is saved: 7 for “Soon”, 14 for “Kind of Soon”, and 30 for “Not Soon”
• The last purchased date should be set to null initially (i.e. you can create an item without purchasing it)
• Item names should be displayed as a simple, unordered list on the list view after they’re added

A shopping list consists of a set of items associated with a user’s token. Creating a new list consists of the following sequence:

• Generate a new, unique token
• Save the token to localStorage
• Show the user the list view

The following script should be used to generate a suitable token: src/lib/tokens.js

AC:

• For users who do not already have a token/list, a button or link exists on the home screen that allows them to create a new list
• Clicking the button/link generates a new token and saves it to localStorage
• Once the token has been created and saved, the user is redirected to the "list" view

AC:

• Display a text field above the top of the shopping list
• As the user types into the field, the list should narrow to display only items that contain the text the user entered in the filter field
• When the field has text in it, the user should be able to tap a UI element (e.g., with an "X" button next to the field) to clear the field
• The filter text should match any part of the item name (i.e. it should not only match from the start of the string)