2 min read
Presentation LayerLast Updated - Platform 22.0.0 - SDK 17.0.0
The presentation layer contains the coordinators, views, state, reducers and feature specific middleware. For presentation we use the Redux architecture.
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 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, 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
withMiddleware functions to allow you to add additional reducers and middleware.
As well as
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 (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.
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
View controllers can dispatch actions via their store using the
We also provide a number of convenience methods for dispatching certain types of actions such as for navigation using
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.
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.
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 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.