Presentation Layer

The presentation layer contains the coordinators, views, state, reducers and feature specific middleware. For presentation we use the Redux architecture.

• Coordinators
• Builders
• View Controllers
• Redux Stores
• ViewData
• ViewData Mappers
• Views

Feature frameworks contain the presentation layer of that feature(s). They may contain the domain layer if the feature is very simple, standalone or does not require an API.

Coordinators

Coordinators make the dependencies of, set up and handle navigation to, and forward from, the feature they are for. Coupled with dependency containers and runtime modules, coordinators allow the SDK to fully set up features out of the box with no code.

All SDK services are created as protocol interface / class implementation pairs but it's easiest to subclass the Poq prefixed implementation.

Builders

Builders, following the builder pattern, provide an interface for you to add customisations to a Redux enabled feature's main view or view controller.

All SDK builders have withReducer and withMiddleware functions to allow you to add additional reducers and middleware. As well as withXMiddleware where X is a common type of middleware such as for analytics, navigation, interaction...

With newer view controllers and widgets we have started to move away from builders in favour of subclassing to steer tidier customisations.

View Controllers

View controllers (or widgets) are the owners of their feature where they hold references to a Redux store, their view data mapper and their main view. They subscribe to Redux store updates with a newState function where they map the state to view data and pass it to their views.

Widgets are a term we have given to views that own a Redux store (are their own feature) even though they are not, by UIKit's definition, a screen.

Redux Stores

View controllers are built with a Redux Store object that wraps together the initial State, Reducers and Middleware. Whenever an action is dispatched to the Store it may result in a new State which the ViewController (or widget) subscribe to with the newState function.

View controllers can dispatch actions via their store using the store.dispatch. We also provide a number of convenience methods for dispatching certain types of actions such as for navigation using NavigationDestination objects.

Views can dispatch actions either via delegation to the ViewController or in some cases via a DispatchingStore which is a simple Store reference without access to it's State.

ViewData

View data models contain the UI specific data for a view or set of views. They are more specific to views and are mapped from the state / or domain models following a new state.

• How do I create ViewData?
• How do I pass custom ViewData to a view?

ViewData Mappers

View data mappers map from the state and / or domain models to the view data used by specific SDK views. Often the view controller owns the top level mapper which has sub mappers that map sub view data.

Most SDK view data mappers forward the custom data of the domain model as is. This allows you to use your custom domain data from the view directly with no code elsewhere.

Views

Views are the UI of a feature. Any view can be replaced with one line via the shared dependency container.

Views within the SDK are set up programmatically to allow them to be easily customised whilst avoiding copy-paste. Most views conform to our own View protocol for consistency and consist override points.

All views commonly have setup(with viewData:) functions; however, we use this to update the view with this view data following a new state.