[Analytics Hub] Add fake order stats for configuring Analytics cards

[rachelmcr]

Closes: #8190

Description

This PR adds a set of fake OrderStatsv4 data we can use to configure the Revenue and Order Analytics cards until real data is integrated into the Analytics Hub (in #8189).

Submitter Checklist

Update release notes:

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[peril-woocommerce]

	Warnings
⚠️	This PR is assigned to a milestone which is closing in less than 2 days Please, make sure to get it merged by then or assign it to a later expiring milestone

Generated by 🚫 dangerJS

[Ecarrion]

Code looks good but I fail to see the benefit of this fake data, is it to test the helpers? 🤔

[Ecarrion]

What's the reason for these to be published properties? 🤔

[rachelmcr]

I thought if we make them published properties, we can listen for changes to the data (i.e. when a different time period is selected and new data is synced) to update what is displayed on the cards. WDYT?

[rachelmcr]

@Ecarrion I thought it would be useful so we can split the work of integrating the Yosemite layer (retrieving real OrderStatsV4 data for the current and previous periods) and using OrderStatsV4 data to configure the Orders and Revenue cards (which can be done with the fake data for now). Related discussion: p1669207327936629/1669206497.378969-slack-C02KUCFCSFP

Is there a better way to split up that work so we can do it in parallel? I'm open to anything; this just seemed like a simple solution.

[rachelmcr]

It just occurred to me that we don't need all the fake data to get started with this if we just set the order data properties to nil:

    /// Order stats for the current selected time period
    ///
    @Published private var currentOrderStats: OrderStatsV4? = nil

    /// Order stats for the previous time period (for comparison)
    ///
    @Published private var previousOrderStats: OrderStatsV4? = nil

This is simpler and should still be appropriate as a starting point for splitting up the work (we won't have any order data until we perform the remote sync, so the view model should be initialized with nil order data in any case).

[Ecarrion]

Hmmm, I don't know 😓

I was thinking that the "how we store the data" was going to depend on how we fetch it. For example, on my mind, we would have done something like

rangeTrigger()
   .fetchStatsData()
   .bindToCardsVMs()

So if we go with that route, we don't need to store the stats data response, does that make sense?
For that reason, I normally wouldn't get ahead of myself on how I store the data here. Am I missing something?

In any case, we can always delete this if it doesn't serve our purpose, so feel free to merge it as it wouldn't cause much harm, I hope 😛

[rachelmcr]

Ah, gotcha. Because the stats store doesn't return the stats response directly (only upserts it into storage) I figured we'd store the data in the view model and do the fetching separately from the binding to card VMs:

rangeTrigger()
   .fetchStatsData()
   .updateDataPropsFromStorage()

observeDataProps()
   .maptoCardVMs()

But as you said we can delete this later if it doesn't serve our purpose, and any work that we've done in parallel could be stitched together if we decide not to store the data like this. I'll make the change I mentioned earlier and then merge this.

[wpmobilebot]

You can test the changes from this Pull Request by:

• Clicking here or scanning the QR code below to access App Center
• Then installing the build number pr8191-5bfcbed on your iPhone

If you need access to App Center, please ask a maintainer to add you.