Should we have a result builder to merge effects and/or reducers?

[notcome]

Motivation

For certain actions, several effects can be created and needed to be merged together. One pattern I use is to have a .start action where I start all sorts of subscription for pulling external data. In such cases, I find myself have to manually merge effects. There are three ways to do that, but IMO none of them are perfect:

1. I can write a huge Effect.merge like Reducer.combine.
2. I can manually name each effect, and write a Effect.merge(...) at last.
3. I can put them all into an array, but then I have to write effects.append(someMultilinePublisher.eraseToEffect).

This is not totally unbearable, but wouldn’t it be nice to have a result builder? We no longer need to worry about the commas, no more eraseToEffect, no more variable naming. Plus we can also support it/switch/for-loops.

A naïve implementation could look like this:

@resultBuilder
struct EffectBuilder<Output, Failure: Error> {
    typealias Component = [Effect<Output, Failure>]
    typealias FinalResult = Effect<Output, Failure>

    static func buildExpression<P: Publisher>(_ publisher: P) -> Component where P.Output == Output, P.Failure == Failure {
        [publisher.eraseToEffect()]
    }

    static func buildOptional(_ component: Component?) -> Component {
        component ?? []
    }

    static func buildEither(first component: Component) -> Component {
        component
    }

    static func buildEither(second component: Component) -> Component {
        component
    }

    static func buildArray(_ components: [Component]) -> Component {
        components.reduce(into: []) { $0 += $1 }
    }

    static func buildPartialBlock(first: Component) -> Component {
        first
    }

    static func buildPartialBlock(accumulated: Component, next: Component) -> Component {
        accumulated + next
    }

    static func buildFinalResult(_ component: Component) -> FinalResult {
        switch component.count {
        case 0:
            return Effect.none
        case 1:
            return component[0]
        default:
            return Effect.merge(component)
        }
    }
}

extension Effect {
    init(@EffectBuilder<Output, Failure> content: () -> Self) {
        self = content()
    }
}

Then we can write something like:

return Effect {
    state.window.publisher(for: \.frame)
        .map(BrowserWindowAction.updateFrame)

    state.windowScene.catalystWindowFuture
        .flatMap { window in
            window.fullScreenPhase.map(BrowserWindowAction.updateFullScreenPhase)
        }
}

instead of

return Effect.merge(
    state.window.publisher(for: \.frame)
        .map(BrowserWindowAction.updateFrame)
        .eraseToEffect(),
    state.windowScene.catalystWindowFuture
        .flatMap { window in
            window.fullScreenPhase.map(BrowserWindowAction.updateFullScreenPhase)
        }
        .eraseToEffect()
)

[mbrandonw]

This is definitely interesting idea, and @tgrapperon has shared some explorations into this area recently too.

I think currently we do not want to invest too much more time in building out niceties for Effect as a publisher because soon most uses of Combine for effects will be replaced with async await. For example, to fire up a long-living sequence and async unit of work in parallel we could do something like this:

return .run { send in 
  await withTaskGroup(Void.self) { group in 
    group.addTask {
      for await value in environment.sequence() {
        send(.update(value))
      }
    }
    group.addTask {
      send(.updateOther(await environment.fetch()))
    }
  }
}

This Effect.run tool isn't public yet, but it's something we are actively working on.

[tgrapperon]

@notcome Here is the experiment @mbrandonw is referring to.