Defining Events and Effects

Event and Effect objects are very similar. They have different roles in a Mobius loop, but both are values that get passed around as messages. As a consequence, both events and effects usually get defined in the same way, and it is frequently a good idea to define them using the same pattern. In the rest of this document we refer to them collectively as messages.

Different ways to define messages

From the Mobius framework’s point of view, the message types are opaque, so it’s up to you to define what they are and what they mean. The sole constraint is all instances of a kind of message must have a single type that they implement. So all Events for a given loop must share a type, and all Effects must share a type.

We recommend using enumerations with associated values to define messages.

Simple messages can be defined without associated values:

enum CounterEvents {
    case increment
    case decrement
}

More sophisticated events/effects may require some additional data to be useful:

enum CounterEffects {
    case reportFailure(reason: String)
}

That being said, any value type can be used to represent both events and effects.