Effects with completions

[dankinsoid]

I found it useful to add completions to effects, where completions itself are small reducers:

return .run { send in // also it would be nice not to require `send` argument here
  // some task here
}
.then { state in
    state.counter += 1
    state.string = nil
}.catch { error, state in
    state.string = "\(error)"
}.finally { state in
    state.isLoading = false
}

and even more, they could optionally return new effects:

return .run { send in 
  // some task here
}
.then { state in
    state.counter += 1
    state.string = nil
    return .send(.someHighlyReusableAction)
}.catch { error, state in
    state.string = "\(error)"
}.finally { state in
    state.isLoading = false
}

[stephencelis]

@dankinsoid I'm not sure how this would work in practice. Currently, all state mutations happen in the body of the reducer given some action. Because the mutations in your snippet aren't tied to any action or the body of the reducer, I'm not sure I understand how it could be compatible with TCA's testing/debugging tools.

I do agree that some of the ping-ponging of feature state and effects today are annoying, and we do have some plans to make it less annoying in the future, but I think you'd need to sketch your idea out a bit more for us to have a clear idea of how it would work in practice.

[dankinsoid]

Hello! I don’t plan to go into implementation details related to TCA, just sharing the idea from my project that might be useful for you

[Alex293]

You can hack around using a BindingReducer/Action

.run {
  ...
} catch: { _, send in
    await send(.set(\.isLoading, false))
}