RxRedux for Swift / iOS development

[Abhi Muktheeswarar]

I have been using RxRedux with Clean Architecture inside a domain layer (pure java / kotlin module) where I have the state machines. I recently started working on iOS apps. So, I'm exploring the possibilities for sharing a similar domain layer which has all the business logic and state machines. Since RxRedux is based on RxJava and Rx is also available in Swift as RxSwift, if there any plans to release a RxRedux version for iOS development / Swift.

[Hannes Dorfmann]

Right now we are not actively working on a RxRedux Swift version. However, it should be straight forward to port it to swift.

Moreover, we experiment around with coroutine based redux implementation called CoRedux. This might (or might not) end up in a kotlin native multiplatform solution that would allow writing business logic with kotlin and coredux for both, android and iOS.

[Abhi Muktheeswarar]

Thanks for the update. Yeah, it is pretty straight forward to port it to Swift.
So far, have you used a similar concept to RxRedux in iOS development?
Waiting for CoRedux!

[Hannes Dorfmann]

No we havent. Our iOS team doesn't use RxSwift. But I can't see why it should not work nicely on iOS as well (have done iOS development in the past)

[Hannes Dorfmann]

Oh, and no guarantees about CoRedux .... expectation management ... its possible that this will remain an experiment, but its also possible that this will workout ...

[jhowens89]

Not sure if this really fits your particular scenario, but at my work I had the desire to port over architecture pieces to our iOS project. The iOS team is not familiar with Rx, so I felt simply porting it over using RxSwift wouldn't be fair to them considering the learning curve associated with Rx. Instead I pulled in the classes from these Redux implementations:

• https://github.com/ReSwift/ReSwift
• https://github.com/ReSwift/ReSwift-Thunk

and tweaked a snippet of the Store.swift code like such so that it would account for the differences in RxRedux and normal Redux.

Before:

// Wrap the dispatch function with all middlewares
        self.dispatchFunction = middleware
            .reversed()
            .reduce(
                { [unowned self] action in
                    self._defaultDispatch(action: action) },
                { dispatchFunction, middleware in
                    // If the store get's deinitialized before the middleware is complete; drop
                    // the action without dispatching.
                    let dispatch: (Action) -> Void = { [weak self] in self?.dispatch($0) }
                    let getState = { [weak self] in self?.state }
                    return middleware(dispatch, getState)(dispatchFunction)
            })

After:

//Meant just to placehold for the reducer when the ordering had it last
        let noOpAction: DispatchFunction = { _ in ((Action) -> Void).self }
        // Wrap the dispatch function with all middlewares
        self.dispatchFunction = { action in
            self._defaultDispatch(action: action)
            let sideEffects = middleware
            .reversed()
            .reduce(noOpAction,
                { dispatchFunction, middleware in
                    // If the store get's deinitialized before the middleware is complete; drop
                    // the action without dispatching.
                    let dispatch: (Action) -> Void = { [weak self] in self?.dispatch($0) }
                    let getState = { [weak self] in self?.state }
                    return middleware(dispatch, getState)(dispatchFunction)
            })
            sideEffects(action)
        }

It's turned out pretty well so far. State machines have such defined inputs and outputs that you can hide the implementation details pretty well, but the lack of Rx gives me more confidence that if they had to dig into that code, they would understand more of it.

I'm curious to hear about your experience with RxRedux and clean architecture. We have a similar setup, but the majority of our state machines are in the presentation layer. This is because most of them map to a screen or a part of a screen (similar to the example project here). However, there are also state machines in the domain layer that multiple state machines in the presentation layer might observe. For instance, we have an video queue that is observed by multiple UI-centric state machines. I can see the argument for putting all state machines in the domain layer, but I have a hard time getting over the fact that they are so coupled to the UI details.

[Abhi Muktheeswarar]

Thanks for the update @jhowens89. Interesting, I haven't thought much about using ReSwift, since I'm focusing on having a similar setup as close as possible to the Android. But with your comment, I'll revisit it. I used RxRedux with clean architecture in three production apps so far. I use it only in domain layers, so far never encountered a scenario to use in the presentation layer. The only drawback is a steep learning curve for a new developer to understand everything. Curious to know what ur doing with state machines in the presentation layer.

[Hannes Dorfmann]

In case kotlin multiplatform is an option: you may like this project of us https://freeletics.github.io/FlowRedux/dsl/