Sd ia estimate next purchase

[sandaiiyahh]

For an example of how to fill this template out, see this Pull Request.

Description

• Added new variables to itemTemplate: numberofPurchases and daysUntilPurchase
• numberOfPurchases is the number of times an item has been purchased. Any time an item is checked, this value increments by 1.
• daysUntilPurchase is the calculated result of the calculateEstimate function
• Declared a latestInterval initially set to frequency, which will be used inside the calculateEstimate function. latestInterval is the current date minus the previously purchased date, in the form of # of days.
• Used calculateEstimate inside the handleChange function
• Stored milliseconds conversion into a variable mlsPerDay
• Changed firestore from .set to .update to save having to set variables each time

Thoughts We Had:

• Should frequency be used when calculating the estimate?
• Not sure if the daysUntilPurchase updates accurately. Will need to calculate on our own to test it

UPDATE:

• Used frequency as initial latestInterval value to be used in calculateEstimate function
• Added a condition inside the handleChange to check if the checkbox is checked before using the calculateEstimate function so that it doesn't update when the checkbox is both check and unchecked
• daysUntilPurchase is now set to nextPurchaseDate or daysUntilPurchase -- daysUntilPurchase so that it doesn't update when the box is unchecked

Related Issue

closes #10

Acceptance Criteria

• [x] When a purchase is recorded, the estimated number of days until the next purchase date should be calculated and recorded in the database
• [x] The script at /src/lib/estimates.js should be used to calculate the next estimated purchase interval.

Type of Changes

	Type
	:bug: Bug fix
✓	:sparkles: New feature
✓	:hammer: Refactoring
	:100: Add tests
	:link: Update dependencies
	:scroll: Docs

Updates

Before

After

Variables are initially declared when you first add an item:

After checking off an item as purchased:

After an item has been purchased more than 2 times:

Testing Steps / QA Criteria

• Pull down branch sd-ia-estimate-next-purchase
• Add a new item
• Check off item to mark as purchased
• Change lastPurchasedDate of item in firestore to a date before the previous purchase
• Once item has reached over 2 purchases, the daysUntilPurchase should change

[github-actions[bot]]

Visit the preview URL for this PR (updated for commit daff347):

https://tcl-28-shopping-list--pr32-sd-ia-estimate-next-atpbv9td.web.app

_{(expires Fri, 20 Aug 2021 23:24:31 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

[meganesu]

Nicely done y'all! Like others have said, this was a complicated ticket, and you did a great job sticking with it! Well done 🥳

A few thoughts in response to @luisaugusto's review: (happy to discuss more tomorrow in Slack!)

There is one issue where if you uncheck an item because you accidentally clicked, there is no way to undo the calculation that you already made, so you can keep toggling the checkbox to alter the data for the item with no way to revert.

Personally, in the interest of time (since I know y'all have already spent quite a while working on this), I'd suggest we create another story to handle undoing accidental purchase calculations, since that functionality is not explicitly included in the acceptance criteria for this ticket.

I noticed that there are currently three fields in Firebase: isPurchased, lastPurchasedDate, and numberOfPurchases. What I would recommend doing is consolidating those three fields into one purchaseDates array.

Similarly, I got the impression from @segdeha's comment in Slack that storing a list of all the purchase dates is also out of scope.

For older items in lists that were made before this change, the numberOfPurchases field is returning NaN, it would be good to check this and default it to 0 if it's missing in an older item without the field.

Agreed, adding a quick check and default value is a good idea. During office hours, we'd debated dumping the existing documents in the database and starting from scratch (since it's a small project and we don't have any real users yet). But in a real professional setting, that wouldn't be an option, since odds are you'd already have a bunch of user data in the database.

[isaabutaa]

Hey @meganesu @luisaugusto thank-you both for the feedback and suggestions. Since it was rather small, I committed the change that Luis suggested:

• changed ? numberOfPurchases + 1 : numberOfPurchases to ? numberOfPurchases + 1 || 1 : numberOfPurchases
• Also implemented Number(frequency) in a couple places to ensure that frequency is saved as a Number going forward