SwiftRex Versions Save

Xcode 13 CocoaPods fixes (#125) - reported by @DJBen liftToCollection on MiddlewareProtocol (#123) - thanks @marcusficner

CombineRex cancellation was still broken due to the incorrect use of .receive(on:) together with .handleEvents(receiveSubscription:). The scheduler is used to deliver output, not subscription. When fixing to the correct receiveOutput event, the DispatchQueue.main was lazy, always dispatching the cancellation into the next runloop, even when the block was already in the main queue.

For that purpose, it was created ASAPScheduler, that internally uses the already present DispatchQueue.asap extension created in the SwiftRex core. This block checks the current queue and, in case it's the main queue, performs the operation block immediately. Otherwise, if calls DispatchQueue.main.async. As a Combine Scheduler, this is useful to perform actions immediately (as ImmediateScheduler) when the current queue is the main.

In some rare situations, EffectMiddleware cancellation could not happen immediately and some leftover actions could still be forwarded, or it could behave incorrectly when a publisher is replaced by another using the same token (which should cancel the first and keep the second, but it could cancel both).

More tests to ensure this part is reliable and all cases are covered.

• RxSwift updated to 6.2
• ReactiveSwift updated to 7.0
• IO.run is now public. Use it only from test libraries, as in normal situations only Store should perform IO. Exception allowed: when IO.run is called inside the context of another IO block, however for that case you should favour flatMap or other compositional/monadic operators instead.

To replace protocol Middleware, we introduced the new protocol MiddlewareProtocol, also known as "IO Middleware", that has a more appropriate lifecycle and avoids side-effects not directly caused by incoming actions. Please read the documentation for more information how to use it.

The old Middleware is deprecated and will be removed once the 1.0 is released. The new IO Middleware can be considered stable and its contract is not expected to change anymore.

EffectMiddleware is built on top of IO Middleware now, and didn't change. If you are comfortable with reactive programming, EffectMiddleware should be your choice, only falling back to IO Middleware when you look for something more imperative (analog to Haskell IO Monad).

The only expected change before 1.0 now is the introduction of a Async/Await Middleware, built on top of IO Middleware, that allows Swift co-routines.

THIS IS THE LAST VERSION THAT SUPPORTS XCODE 12

To replace protocol Middleware, we introduced the new protocol MiddlewareProtocol, also known as "IO Middleware", that has a more appropriate lifecycle and avoids side-effects not directly caused by incoming actions. Please read the documentation for more information how to use it.

The old Middleware is deprecated and will be removed once the 1.0 is released. The new IO Middleware can be considered stable and its contract is not expected to change anymore.

EffectMiddleware is built on top of IO Middleware now, and didn't change. If you are comfortable with reactive programming, EffectMiddleware should be your choice, only falling back to IO Middleware when you look for something more imperative (analog to Haskell IO Monad).

The only expected change before 1.0 now is the introduction of a Async/Await Middleware, built on top of IO Middleware, that allows Swift co-routines.

THIS IS THE LAST VERSION THAT SUPPORTS XCODE 12

Small improvement to allow usage from TestingExtensions:

• AfterReducer, in debug, now offers a way to call reducerIsDone so TestingExtensions can use it without having to use testable import.

Fixes a memory leak that could occur in some cases when ObservableViewModel was created inside the SwiftUI View's init, due to excessive amount of inits and deinits that happen in a SwiftUI lifecycle.

Thanks to @Overcot for finding and fixing this issue.

Please report if you still encounter any possible problems on ObservableViewModel due to SwiftUI lifecycle.

Some small improvements on lift to collection (ElementIDAction and ElementIndexAction are now Codable and Equatable when internal action also conforms to those protocols. Non-mutable version of Reduce function is now deprecated. To be removed in 1.0. Please use mutable version for better performance. Module exports to avoid importing SwiftRex when you already import CombineRex/RxSwiftRex/ReactiveSwiftRex.

v0.8: EffectMiddleware v0.8.1: hotfix - Effect.promise to allow escaping closures v0.8.2: hotfix - allow SPM to be used with Xcode 11