# Comonadic UIs

Now that we have presented Monads and Comonads, and their Pairing relationship, let’s see how this plays a role on building user interfaces. We will do it following our intuition in an example.

## A SwiftUI View

Let’s build a SwiftUI View according to how it is recommended in the framework documentation. We can create a view to show a stepper:

```
struct StepperView: View {
@SwiftUI.State var count: Int
var body: some View {
HStack {
Button("-") { self.count -= 1 }
Text("\(count)")
Button("+") { self.count += 1 }
}
}
}
```

A view in SwiftUI must implement the `View`

protocol, imposing the implementation of a `body`

property that describes its internal structure. It provides built-in widgets, like `HStack`

, `Button`

and `Text`

to render the view. SwiftUI also provides the `@State`

property wrapper, which is used to observe state changes and trigger redraws of the view.

We can observe some problems with this approach. First of all, business logic is entangled in presentation logic. We could extract it, but still the view will have to know which logic needs to be invoked. Second, the view is based on mutable state, which could potentially result in difficulties to reason about the code.

## View as a function of immutable state

Let’s try to rewrite the previous view in a different way:

```
enum StepperInput {
case tapDecrement
case tapIncrement
}
struct StepperView: View {
let count: Int
let handle: (StepperInput) -> Void
var body: some View {
HStack {
Button("-") { self.handle(.tapDecrement) }
Text("\(count)")
Button("+") { self.handle(.tapIncrement) }
}
}
}
```

With this version we have performed some small changes that may have a profound implication:

- View is a function of immutable state. We have lost the ability to trigger changes on it, but we will retrieve it later.
- Logic is stripped out of the view; instead, the view communicates events through a function.

With this, we have achieved that our View is now a function:

`(Int, (StepperInput) -> Void) -> StepperView`

If we use `S`

for a generic state, `I`

for a generic input, and `V`

for a generic views, we could be modelling all of our views as a function:

`view :: (S, (I) -> Void) -> V`

## Handling inputs

Let’s focus on the input handling function. Its signature is `(I) -> Void`

. The only way a function with that signature could be implemented as a pure function is to have an empty body; therefore, we must assume this function is performing side effects.

On the other hand, handling the inputs produced by user interactions on the view should trigger state mutations. In order to perform those state mutations, we may also need to perform side effects. State mutations can be modeled using the State Monad; in particular, if our mutations are not producing any other values, we can model such mutations using `State<S, Void>`

, given our state has type `S`

. As for side effects, we can model them using `IO`

.

Therefore, we could split the original function `(I) -> Void`

as:

`(I) -> IO<Error, State<S, Void>>`

`(IO<Error, State<S, Void>>) -> IO<Error, Void>`

`(IO<Error, Void>) -> Void`

As you can see, the output type of a function matches the input of the following; thus, if we compose them, we can have our initial `(I) -> Void`

.

The first function `(I) -> IO<Error, State<S, Void>>`

is a function that must be provided to interpret how to map inputs to state mutations. It describes the application logic, and therefore must be provided for each specific case. In Bow Arch, it is modeled as a `StateDispatcher`

.

The second function has a signature `(IO<Error, State<S, Void>>) -> IO<Error, Void>`

. If we pay attention to the types of the input an output of this function, we can infer that this function will somehow handle the state transitions, as the `State<S, Void>`

“disappears”; therefore, it should be applied within the implementation of this function. In Bow ARch, we will refer to this function as the `StateHandler<S>`

.

```
typealias StateHandler<S> = (IO<Error, State<S, Void>>) -> IO<Error, Void>
```

The third function on this list is a well known function; the sensible implementation for this function would be to `unsafeRun`

the `IO<Error, Void>`

value to perform the described side effects.

## Representing a user interface

If we step back a bit, our view function was:

`view :: (S, (I) -> Void) -> V`

We have seen that `(I) -> Void`

can be decomposed into three parts, from which we can take the second part to take care of the state transitions; we will see later how we plug in the two other pieces. We can rewrite this function as:

`view :: (S, StateHandler<S>) -> V`

And currying this function would yield:

`view :: (S) -> (StateHandler<S>) -> V`

For convenience, we can create a new structure `UI<S, V>`

, that is, a `UI`

is a function that, when provided a way of handling state transitions, will yield a view.

```
typealias UI<S, V> = (StateHandler<S>) -> V
```

So, our view function can be finally rewritten as:

`view :: (S) -> UI<S, V>`

That is, given a state of type `S`

, it will provide a user interface that handles state transitions of type `S`

and shows this state on a view of type `V`

.

## Describing the space of possible UIs

With the changes we did at the beginning we lost the ability to update the state, as we made the view a function of immutable state. We can restore this ability by making use of the Store Comonad.

A Store definition is:

```
struct Store<S, A> {
let state: S
let render: (S) -> A
}
```

Our `view`

function has the same shape as the `render`

function in Store, and we can restore state handling using the `state`

property of Store. Therefore, we can put everything together as:

`store :: Store<S, UI<S, V>>`

This store models the space of all possible UIs that we can have with state `S`

and drawn as a view `V`

.

## Performing state transitions

So far we are able to model the space of possible states, but how are state mutations applied? We know that Pairings will help in this regard. The pairing function between State and Store is:

```
func pair<S, A, B, C>(
_ fa: State<S, A>,
_ gb: Store<S, B>,
_ f: @escaping (A, B) -> C
) -> C {
let (newS, a) = fa.run(gb.state)
let b = gb.render(newS)
return f(a, b)
}
```

We can write a new function in terms of `pair`

:

```
func select<S, B>(
_ fa: State<S, Void>,
_ gb: Store<S, Store<S, B>>
) -> Store<S, B> {
pair(fa, gb) { void, store in store }
}
```

As usual, let’s read the types of this function. It receives a state mutation that produces no other value (`State<S, Void>`

), and a value `Store<S, Store<S, B>>`

.

If a `Store<S, B>`

represents the space of possible `B`

values that can be rendered from a state `S`

, then `Store<S, Store<S, B>>`

represents the space of possible spaces of `B`

values that can be rendered from an `S`

value. It is as if we were able to inspect all possible future states where we can transition to from the current one we are in, and use the State mutation to `select`

one of them.

How can we use this now? Well, we haven’t still provided an implementation for our `StateHandler<S>`

function, and `select`

is what we need to do its implementation. We can put everything together as a Component:

```
class Component<S, V>: ObservableObject {
@Published var store: Store<S, UI<S, V>>
init(store: Store<S, UI<S, V>>) {
self.store = store
}
func explore() -> V {
// (1) Extract obtains the UI in the current state
let ui: UI<S, V> = store.extract()
// (2) We provide an implementation of the StateHandler<S>
// in order to obtain a view of type V
return ui { (action: IO<Error, State<S, Void>>) in
// (3) When an action is received,
// we access the state mutation
action.flatMap { (stateMutation: State<S, Void>) in
// (4) Use the mutation to select the next store
let nextStore: Store<S, UI<S, V>> = select(stateMutation, self.store.duplicate())
// (5) And finally, we update the Store with the next state
// that will be rendered
return IO<Error, Void>.invoke {
self.store = nextStore
}
}^
}
}
}
```

Despite how abstract these concepts are, the process is not very complex. Finally, in order to make sure our SwiftUI rendering updates every time a state transition occurs, we can make:

```
struct ComponentView<S, V: View>: View {
@ObservedObject var component: Component<S, V>
var body: some View {
self.component.explore()
}
}
```

Calling explore will obtain the current view for the state saved on the Store. When a user interface event occurs, it will be processed in the flow above, will trigger a new Store, and the `ObservedObject`

property wrapper will notice a change, that will result in a new rendering of the UI.

## Generalizing these ideas

So far we have described how these ideas are applicable for State and Store; however, the reasoning can be generalized, as the “magic” of this approach resides on the notion of Pairing between a Monad and a Comonad.

In fact, the `explore`

function does not need to know it is dealing with State and Store; it just uses a `select`

function, which is a function that can be derived from `pair`

. Therefore, `explore`

can be written as a generic function that operates on a Comonad, and its Pairing Monad.

If we take this approach, we can review our entire reasoning to define the building blocks of the Comonadic UIs approach as using a Monad `M`

and a Comonad `W`

that pair with each other:

`Handler<M: Monad> :: (IO<Error, M<Void>>) -> IO<Error, Void>`

`UI<M: Monad, V> :: (Handler<M>) -> V`

`Component<W: Comonad, M: Monad, V> :: W<UI<M, V>>`

Moreover, we are using `IO`

to model side effects here, but nothing stops us to abstract over this as well. We could be using other type to deal with side effects. In this case, if we use an abstract `Eff`

type, the final result is:

`Handler<Eff, M> :: (Eff<M<Void>>) -> Eff<Void>`

`UI<Eff, M, V> :: (Handler<Eff, M>) -> V`

`Component<Eff, W, M, V> :: W<UI<Eff, M, V>>`

With this model, we can yield different architectures, letting us choose the type we will use to model side effects (`Eff`

), the type to model UI actions (`M`

) and the space of possible UIs (`W`

).

## Conclusion

Bow Arch provides a general implementation of this model, and additional syntax sugar over the State-Store pair, which will ease the usage of the library.

The actual implementation is a bit more complex, but not too much; concepts presented here have been simplified for the sake of pedagogy.

Do not worry if you do not get it on the first read. It will take time for the ideas to percolate, and you will discover new things every time you read these docs. An effective way of understanding it is to actually try to write the code, at least in a non-generic way. It will help you see these concepts in practice. And if you get stuck, feel free to open an issue on the library repository, or contact the developers of the library.