Dashboard: Orders to fulfill

[aforcier]

As a store owner I want a quick way to see how many open orders I have, and have a quick way to go directly to a list of them.

Relies on #282, so we can open the order list filtered to 'Processing' orders.

TODO

FluxC

• Fetch orders filtered by the order status "processing" - these would not be saved in the database, but instead used just to grab a count. We don't want to save these changes in the database because the orders view may currently be filtered by something entirely different and the database is currently refreshed after every filter change.

UI

• On first load or force refresh of dashboard, grab total count from FluxC
• Create a new view (not generic, we'll convert it later if variations are needed)
• Add view to dashboard, visible only if there are orders waiting for fulfillment
• Add click event to open the orders view filtered by "processing"
  -- this should always force a refresh of the data, even if the view is already filtered by orders.
• Refresh dashboard on initial load and then anytime an onOrderChanged event that is NOT the event to fetch order count is fired (deferred refresh if dashboard not active)
• Add unit tests for any Dashboard contract changes

[AmandaRiu]

@aforcier :

This one is a bit tricky due to the non-caching nature of our app so far, so I'd like to get some feedback on my plan so far, as well as some clarifications around some questions. Here's how I plan on implementing this solution:

• Create a new view (planning on keeping it generic so it can be recused with other dashboard notifications)
• Add dashboard event to fetch orders filtered by "processing" - these would not be saved in the database, but instead used just to grab a count. We don't want to save these changes in the database because the orders view may currently be filtered by something entirely different and the database is currently refreshed after every filter change.
• Add view to dashboard, visible only if there are orders waiting for fulfillment
• Add click event to open the orders view filtered by "processing"
  -- this should always force a refresh of the data, even if the view is already filtered by orders.
• Add unit tests for any Dashboard or OrdersList contract changes

Question 1: When should we refresh this view? It can quickly get out of sync. currently the design in place is to only pull fresh on load and then the user manually refreshes the view, or refresh after a change...so for sure we'd do the following:

• Whenever a new action is performed on an order inside the app, such as a change in status or marked complete.
• anything else?

Question 2: Should re-selecting the orders bottom bar option clear the filter if it's already selected?

cc: @nbradbury

[aforcier]

The solution implementation steps makes sense to me 👍

For the second step, perhaps we can store the 'processing' count in memory in the OrderStore to have a central place where it's kept up to date (to decouple 'status of order changed' from 'update count in dashboard card').

I think refreshing when an order is changed covers things well for Question 1 - and when we eventually use received order notifications to trigger a stats refresh we'll also trigger a refresh of this view (the whole dashboard really).

Re Question 2, clearing the filter when reselecting the orders bottom bar is what I would expect to happen personally, but I don't have a strong feeling either way.

[AmandaRiu]

Hey @aforcier I just want to clarify:

For the second step, perhaps we can store the 'processing' count in memory in the OrderStore to have a central place where it's kept up to date (to decouple 'status of order changed' from 'update count in dashboard card').

I think refreshing when an order is changed covers things well for Question 1...

If we're going to be refreshing whenever the order is changed what would be the use case for keeping this value in OrderStore?

[aforcier]

I guess it depends how you were planning to approach refreshing the view - when the order changes, we're in the order list fragment (or one of its child fragments). How do we tell the DashboardFragment to refresh? I'm sure there are several ways (maybe you had a better one in mind), but I was thinking that updating the value in the OrderStore from the OrderListFragment lets us decouple things a bit, since we only need to get the value from the OrderStore when the DashboardFragment is build/visible again.

[AmandaRiu]

@aforcier Ah I see where you were going with that. The only hitch with that is once the order is saved, the orders list view is refreshed and depending on what filter is active, the total count of orders could be different and we wouldn't want to rely on that for the dashboard. I thought about just manually updating this variable if the order is completed, but since the order list gets refreshed it's possible more open orders were picked up in the process so it would still be out of date. I'm thinking I'll use the same sort of mechanism I use with orders - a flag that tells the view it should refresh when it comes to the foreground.