Swiftpack.co - Package - spotify/Mobius.swift

Mobius.swift

CocoaPods Compatible Carthage Compatible Build Status codecov License

Mobius is a functional reactive framework for managing state evolution and side-effects. It emphasizes separation of concerns, testability, and isolating stateful parts of the code.

Mobius.swift is the Swift and Apple ecosystem focused implementation of the original Mobius Java framework. To learn more, see the wiki for a user guide. You can also watch a talk from an Android @Scale introducing Mobius.

This repository contains the core Mobius framework and add-ons for common development scenarios and testing.

Compatibility

| Environment | details | | ----------- |-------------| | 📱 iOS | 10.0+ | | 🛠 Xcode | 10.1+ | | 🐦 Language | Swift 4.2 |

Installation

Mobius.swift supports most popular dependency managers. Choose your preferred method to see the instructions:

CocoaPods

Add the following entry in your Podfile:

pod 'MobiusCore', '0.2.0'

Optionally, you can also choose to integrate MobiusExtras, MobiusNimble or MobiusTest:

pod 'MobiusExtras', '0.2.0'
pod 'MobiusNimble', '0.2.0'
pod 'MobiusTest', '0.2.0'
Carthage

Add the following entry in your Cartfile:

github "spotify/Mobius.swift" "0.2.0"

There are some additional steps to take as explained in the Carthage documentation.

NOTE: At this moment Carthage doesn't have a way to specify subspecs in a single repo. For this reason, Carthage will automatically pull our dependencies used to provide test helpers in MobiusNimble. You can simply choose not to link this library in your project if you don't plan to use it.

Swift Package Manager

Add the following entry to your Package.swift:

.package(url: "https://github.com/spotify/Mobius.swift.git", .upToNextMajor(from: "0.2.0"))

Mobius in Action - Building a Counter

The goal of Mobius is to give you better control over your application state. You can think of your state as a snapshot of all the current values of the variables in your application. In Mobius, we encapsulate all of the state in a data-structure which we call the Model.

The Model can be represented by whatever type you like. In this example we'll be building a simple counter, so all of our state can be contained in an Int:

typealias CounterModel = Int

Mobius does not let you manipulate the state directly. In order to change the state, you have to send the framework messages saying what you want to do. We call these messages Events. In our case, we'll want to increment and decrement our counter. Let's use an enum to define these cases:

enum CounterEvent {
    case increment
    case decrement
}

Now that we have a Model and some Events, we'll need to give Mobius a set of rules which it can use to update the state on our behalf. We do this by giving the framework a function which will be sequentially called with every incoming Event and the most recent Model, in order to generate the next Model:

func update(model: CounterModel, event: CounterEvent) -> CounterModel {
    switch event {
    case .increment: return model + 1
    case .decrement: return model - 1
    }
}

With these building blocks, we can start to think about our applications as transitions between discrete states in response to events. But we believe there still one piece missing from the puzzle - namely the side-effects which are associated with moving between states. For instance, pressing a "refresh" button might put our application into a "loading" state, with the side-effect of also fetching the latest data from our backend.

In Mobius, we aptly call these side-effects Effects. In the case of our counter, let's say that when the user tries to decrement below 0, we play a sound effect instead. Let's create an enum that represents all the possible effects (which in this case is only one):

enum CounterEffect {
    case playSound
}

We'll now need to augment our update function to also return a set of effects associated with certain state transitions. This looks like:

func update(model: CounterModel, event: CounterEvent) -> Next<CounterModel, CounterEffect> {
    switch event {
    case .increment: 
        return .next(model + 1)
    case .decrement:
        if model == 0 {
            return .dispatchEffects([.playSound])
        } else {
            return .next(model - 1)
        }
    }
}

Mobius sends each of the effects you return in any state transition to something called an Effect Handler. Let's make one of those now:

import AVFoundation
import MobiusExtras

class PlaySoundEffectHandler: ConnectableClass<CounterEffect, CounterEvent> {
    override func handle(_ input: CounterEffect) {
        AudioServicesPlayAlertSound(SystemSoundID(1322))
    }
    override func onDispose() {}
}

Now that we have all the pieces in place, let's tie it all together:

// For convenience, we put all our types in one enum
enum CounterLoopTypes: LoopTypes {
    typealias Event = CounterEvent
    typealias Effect = CounterEffect
    typealias Model = CounterModel
}
// And build a Mobius Loop!
let application: MobiusLoop<CounterLoopTypes> = Mobius
    .loop(update: update, effectHandler: PlaySoundEffectHandler())
    .start(from: 0)

Let's start using our counter:

application.dispatchEvent(.increment) // Model is now 1
application.dispatchEvent(.decrement) // Model is now 0
application.dispatchEvent(.decrement) // Sound effect plays! Model is still 0

This covers the fundamentals of Mobius. To learn more, head on over to our wiki.

Status

Mobius.swift is in alpha status. We are beginning to use the framework internally and may still make breaking API changes. The abstractions for threading are the main thing we want to revisit before we feel confident in a 1.0 release. The core concepts of an update function with Models, Events, and Effects are not going to change. Please note that this project may be combined with the Mobius Java repository in the near future.

Development

  1. Clone
  2. Bootstrap the project
    ./Tools/bootstrap.sh
    
  3. Open Mobius.xcodeproj using Xcode.
  4. ????
  5. Create a PR

Code of Conduct

This project adheres to the Open Code of Conduct. By participating, you are expected to honor this code.

Github

link
Stars: 251
Help us keep the lights on

Dependencies

Used By

Total: 0

Releases

0.2.0 - Jun 13, 2019

  • Deprecated CompositeEventSourceBuilder in favour of MergedEventSource (#28)
  • Support Swift 5.1 toolchains (#29)

0.1.2 - Apr 12, 2019

  • Remove xcscheme from Xcode project in order to improve performance when integrating the library with Carthage. (@BalestraPatrick)

0.1.1 - Apr 10, 2019

0.1.0-alpha - Mar 13, 2019