## Data Overview
![Data Overview](./images/data.png)

The image above provides a high-level view of how data flows through the application.

### Example

Here is a step-by-step example of how a data flow for the Home screen Top Tracks' data works:

1. The `HomeScreenContainer` dispatches a `Mount(HOME_SCREEN)` action when the component has been mounted.
2. The `homeScreenSaga` receives the `Mount(HOME_SCREEN)` action
   1. `homeScreenSaga` dispatches a `setHomeScreenLoading(TOP_TRACKS)` action to indicate that the `TOP_TRACKS` task
      is loading.
      1. `homeScreen.reducer` receives the action, and updates the `TOP_TRACKS` `LOADING_STATE` to `LOADING`.
      2. This is read by the `selectTopTracksLoading` selector and passed into the view so that it can react to the 
      loading state.
   2. `homeScreenSaga` dispatches a `requestStarted(GET_TOP_TRACKS)` action to indicate the `GET_TOP_TRACKS`
      request has been initiated (nothing reacts to this action, but it is useful for debugging).
   3. `homeScreenSaga` performs an http call to `bff-mobile` to retrieve track data.
   4. `homeScreenSaga` performs http calls to load top tracks images into the device local image cache.
   5. `homeScreenSaga` dispatches a `requestSucceeded(GET_TOP_TRACKS)` action containing the top tracks
      payload.
      1. `homeScreen.reducer` receives this action and updates the `ISRCS` field of the `TOP_TRACKS` action.
      2. `db.reducer` receives this action and updates the track db to contain the result of the payload.
      3. The db value and the `ISRCS` of `TOP_TRACKS` are joined in the `selectTopTracks` to pass top tracks to the
      view.
   6. `homeScreenSaga` dispatches a `setHomeScreenLoaded(TOP_TRACKS)` action to indicate that the `TOP_TRACKS` task has
   been completed.
      1. `homeScreen.reducer` receives the action, and updates the `TOP_TRACKS` `LOADING_STATE` to `LOADED`.

### Responsibilities

The following sections indicate responsibilities of the various components involved in the application data flow:

#### Screen Components
  * Receive data pertaining to the state of tasks (e.g., `loading` flags).
  * Receive data relevant to the view (e.g., `topTracks` list).
  * Call function props to indicate view lifecycle events (e.g., `this.props.mounted()` called on `componentDidMount`).
  * Makes decisions about what to display based on the state of the view and the available data (e.g., view 
  logic based on task state and provided data might display a loading indicator, a view of stale data with a loading
  indicator, or a zero state).

#### Screen Containers
  * Dispatch actions related to the view state of the screen. This involves events such as `Mounted` when the screen
  is mounted, or `DidBlur` when a navigation event hides the screen.
  * Map selectors to input properties of the corresponding screen component.

#### Screen Selectors
  * Aggregate view state variables and redux-db model data to present models to the view (e.g., `selectTopTracks`
  looks at the list of the view state's `TOP_TRACKS.ISRCS` and joins this with the model data from redux-db to provide
  a list of top tracks to the view).
  * Pass information about the state of tasks to screen container.
  
#### Screen View States
  * Store data related to the identifier(s) of objects displayed by various tasks.
  * Maintain data related to the loading state of the tasks for a screen.
  
#### [`redux-db`](https://github.com/msolvaag/redux-db)
  * Stores raw model data.
  
#### Screen Sagas
  * Perform http requests for loading data.
  * Dispatch actions to update view state of tasks.
  * Dispatch actions for http request lifecycle events.