You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently use ItemListState to define the state of the ItemList, and the fullscreen states used on initial loading of the POS.
The enum effectively defines exactly what should be shown on screen whenever the item list is showing. However, this is defining more than one view at the moment. The fullscreen views are handled by the dashboard, while the loading and loaded views are handled by the ItemListView. We could put all the state handling in the ItemListView and have it pass the fullscreen views up the chain using a preference key, but it would be better to split the state definition up to match what we need.
We'll have a hierarchy of states:
struct ItemsViewState {
var containerState: ContainerState
var itemsStackState: ItemsStackState
}
enum ContainerState {
case loading
case empty
case error(PointOfSaleErrorState)
case content
}
struct ItemsStackState {
var root: ItemListState
}
enum ItemListState {
case loading([POSItem])
case loaded([POSItem])
case error(PointOfSaleErrorState)
}
In future, we'll expand the stack state to have var itemStates: [POSItem: ItemListState]. That will allow the view to open the child views. In this ticket, it's just about splitting up the container state from the list state.
The text was updated successfully, but these errors were encountered:
Description
We currently use
ItemListState
to define the state of the ItemList, and the fullscreen states used on initial loading of the POS.The enum effectively defines exactly what should be shown on screen whenever the item list is showing. However, this is defining more than one view at the moment. The fullscreen views are handled by the dashboard, while the loading and loaded views are handled by the
ItemListView
. We could put all the state handling in theItemListView
and have it pass the fullscreen views up the chain using a preference key, but it would be better to split the state definition up to match what we need.We'll have a hierarchy of states:
In future, we'll expand the stack state to have
var itemStates: [POSItem: ItemListState]
. That will allow the view to open the child views. In this ticket, it's just about splitting up the container state from the list state.The text was updated successfully, but these errors were encountered: