Help! I have been chugging along using ReSwift (on 3.0, Swift3, XCode 8.3) and now for some reason upon initialization ReSwift is crashing (when I run it on my 10.3.1/iPhone7+ thru XCode). I hate these esoteric errors and am hoping beyond hope that someone has experienced anything remotely similar.

AppDelegate has the usual declaration

let store = Store<State>(reducer: AppReducer(), state: nil)

Then my first ViewController subscribes:

override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)
        
        store.subscribe(self) { state in
            state.authenticationState
        }
 }

ReSwift goes through the initialization process until it gets to my AppReducer, and BAM !

Thanks everyone,

--Bill

Here's what I found in the issues and current PRs. Please add and discuss.

I also created a GitHub project from this list, in case that makes contributing to the roadmap any easier: https://github.com/ReSwift/ReSwift/projects/1

Low-Hanging Fruit:

• [x] Fix memory leaks, see #302
• [x] Finish up PR #300 as a fix #298
• [x] Approve #295
• [x] ~Review #231 (generic ActionCreator); it is missing an AsyncActionCreator counterpart~ ActionCreator will be deprecated in favor of ReSwift-Thunk in the future

Breaking Changes

• [x] Perform making state setter private as per #264 (breaking API change, bump to 5.0?)
  • [x] Deprecate ReSwiftRecorder, make outdated dependency on v3.x transparent in the README, look for new maintainers in the community?

Consider including

• [ ] ~Avoid double equatability checks, as per failing #259, needing a fix~ (deferred to post 5.0)

Release Preparation

(Done manually, because #248 never got implemented :))

• [x] Update docs
• [x] Collect contributions for the release notes
• [x] Update README

Thanks a lot to @mjarvis and his work in #190. As part of reviewing his change I noticed some of the aspects that I think could be improved. It would be nice to add a feature that allows skipping state updates that haven't changed a certain substate to the core of ReSwift, as a lot of folks have been asking about that.

However, after some prototyping, I think that the implementation of this should live in the subscription and not in the store. Looking at this prototype, the changes become a lot less invasive that way.

Essentially our subscription type is very, very lightweight reactive component that transforms new values coming out of the store. By keeping the logic in the subscription, we make that reactive component extensible, independent of the rest of ReSwift. We can add a few operators to it (such as skipRepeats) that are going to be used by a majority of developers (however, we should refrain from implementing a full signal library, since enough great libraries exist in that space).

The implementation right now is still pretty hard-wired. I would like to improve this, such that all the transformation logic of new values lives in the subscription and such that various transformations can be composed (as in reactive libraries).

But since I'm almost out of time for this weekend, I wanted to share this working prototype for now.

To-do list

(by @DivineDominion: Just to end up in the PR overview, I pulled the comments here as a todo)

• [ ] Provide alternative API for creating a subscription that doesn't require using a closure
• [x] Make equatable substates use skipRepeats by default
• [ ] Potentially find a new name for Subscription/skipRepeats, though I haven't heard suggestions on this yet.
• [ ] document subscription API change:

    // If the same subscriber is already registered with the store, replace the existing
    // subscription with the new one.
    if let index = subscriptions.index(where: { $0.subscriber === subscriber }) {

I have discovered a likely crash scenario. Please see below.

Store's dispatchFunction var gets assigned in ReSwift/CoreTypes/Store.swift ll. 69–79:

    self.dispatchFunction = middleware
        .reversed()
        .reduce({ [unowned self] action in
            return 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)
    }

However on line 76 we have:

let dispatch: DispatchFunction = { [weak self] in self?.dispatch($0) }

Now, self?.dispatch($0) in turn calls this function on ll. 146-148:

 open func dispatch(_ action: Action) {
     dispatchFunction(action)
 }

In turn, the Store's dispatchFunction function var gets called here. However, at this point, dispatchFunction may be nil because ll. 69–79 may not have completed its task of assigning a value to it yet, and it has no default value. See it's declaration on line 35:

public var dispatchFunction: DispatchFunction!

This may crash when the middleware array is not empty coming into the init function and one of them calls dispatch, since if the .reduce function runs, it may call Store's instance var dispatchFunction before it has been initialized.

EDIT: This will not always happen, but it can happen depending on how middleware is structured. There is also an infinite loop crash that's possible; see below.

Hi, I have some question about using ReSwift and REDUX pattern in modular app.

Modular app is one applications which divided into frameworks. An example to framework can be:

• Core Framework - contains core capabilities which are shared in the app (like: security, user defaults and more)

• Network Framework - contains all the network requests

• UI Frameworks - to share and reuse UI components inside the app like: Buttons, TextFields, Table views and more.

The major part in each modular app is the Feature Frameworks which are a code for specific feature inside the big app. Such features can be: HomeFeature, ProfileFeature, SettingsFeature, FeedFeature and more and more according to the app capabilities. Each feature should not be depend on other feature.

The question is how ReSwift can be used in such architecture? The challenge is how to share the state (which should be global) between the Feature framework. Let's say that we create the AppState on the App level (in the app delegate) and the app is depended on all the Feature framework. Inside each feature framework we will create the specific redux components for this specific feature (e.g. in HomeFeature we will have HomeState, HomeReducer and HomeActions which are relevant only to this feature).

Now, in such architecture the App knows the HomeState and HomeReducer because they are exposed by the Feature framework and we have dependency but the problem is that the Feature framework is not depended on the App and the feature framework don't know what is an AppState or what is a Store so we cannot dispatch actions in it.

I hope that my what I describe above is clear... and would like to hear your thoughts about it. I think ReSwift is a great and very powerful library and if we will be able to create a modular app and still utilize this pattern it will be awesome!

Thanks.

Unidirectional Data Flow and FRP play together nicely. We should consider how to provide an integration of FRP frameworks. Currently it's fairly easy to role your own, on top of Swift Flow, as shown in this example: https://gist.github.com/Ben-G/c33486169d68a6f3d12f

We should consider if integrations should become a core part of the framework or not; related discussion in ReduxKit.

Hi, Thanks for the amazing framework. Currently our project are using it heavily. But as the project grows, we are facing problems. The most common one is the 'EXC_BAD_ACCESS' issue.

This happens when I started to add a new state. The app will crash if the state contains one or more enum properties with associated value. If I simply changed the state to a simpler struct, the app won't crash most of the times. Sometimes, crash also happened when I tried to add a substate inside another substate(Eg: add a state in EntitiesState. I have to move that substate out of the EntitiesState to avoid the crash).

This only happens when we have about hundreds of different states and substates.

I would be very appreciated if you could give me some help. Thanks a lot!

This basically removes the option to select a substate which is Equatable without skipping repetitions.

Why would anybody not want to skip repetitions?

I certainly do, but I don't want to do this using the == operator, especially not for the huge collections of notes I manage in this one app. Right now I cannot pass a substate along directly. Instead, I have to create a subscription wrapper that selects the substate and passes it on to the real subscriber.

I think this side-effect of select hurts, and writing .select(...).skipRepeats() shows at the call site what'll be going on. No surprises.

if I have substate1, substate2 and uiviews filtered subscribers view1, view2 in one ViewController. Now when I change substate2, the newState() is being fired for the view2 and for the view1, although substate1 isn't changed. To fix this I confirms the substates to Equatable protocol and when the newState() is fired check if the new substate is equal to the old one and if it's not then change the view properties.

Is there more practical way to do that? ReduxTest.zip

Hi! Coming from redux I'm really having lots of fun with ReSwift, but I just can't decide what's the best choice for handling reational data in case of swift.

In js world, in redux we mess with normalizr and selectors in order to benefit from normalized state and keep relational data consistent, I assume same pattern applies for ReSwift?

With structs being value types it would require some manual work to keep nested structures consistent, classes on the other hand, don't have all advantages of immutability, but being reference types, they don't need to be synchronized...

So what would be the best approach here?

This implementation allows us to write action creators with return value, just as redux-thunk middleware do. For example it allows composition of action creators this way:

protocol Sauce {
}

protocol SandwichServiceType {
    func getSecretSauce() -> Promise<Sauce>
}

struct MakeSandwich: Action {
    let person: String
    let sauce: Sauce
}

struct Apologize: Action {
    let fromPerson: String
    let toPerson: String
    let error: Error
}

class SandwichActor {
    let service: SandwichServiceType
    init(service: SandwichServiceType) {
        self.service = service
    }
    
    func makeASandwichWithSecretSauce(for person: String) -> ActionCreator<Promise<Void>> {
        return { (store) in
            return self.service.getSecretSauce().then { (sauce) in
                store.dispatch(MakeSandwich(person: person, sauce: sauce))
            }.recover { (error) -> Void in
                store.dispatch(Apologize(fromPerson: "Sandwich store", toPerson: person, error: error))
                throw error
            }
        }
    }
    
    func makeSandwichesForEveryone() -> ActionCreator<Promise<Void>> {
        return { (store) in
            return firstly {
                store.dispatch(self.makeASandwichWithSecretSauce(for: "Grandma"))
            }.then {
                when(fulfilled:
                    store.dispatch(self.makeASandwichWithSecretSauce(for: "Me")),
                    store.dispatch(self.makeASandwichWithSecretSauce(for: "My wife"))
                )
            }.then {
                store.dispatch(self.makeASandwichWithSecretSauce(for: "Kids"))
            }
        }
    }
}

// And finaly use this:

let sandwichActor = SandwichActor(service: realService)

store.dispatch(sandwichActor.makeSandwichesForEveryone())

What do you think about this?

Hi All, given the following class that inherits from StoreSubscriber, I'm trying to subscribe only to a sub-state. But even if another sub-state is updated, then this subscriber is notified about an update.

class PortWindowService: StoreSubscriber {
    typealias StoreSubscriberStateType = ModelState
    
    func start() {
        store.subscribe(self) { $0.select { $0.modelState } }
    }

    deinit {
        store.unsubscribe(self)
    }
    
    func newState(state: ModelState) {
        print(state.ports.count)
        print("ports changed")
    }
}

My app state is:

struct AppState {
    var modelState: ModelState = ModelState()
    var volumeState: VolumeState = VolumeState()
}

struct ModelState {
    var model: StoredModel? = nil
    var ports: [Port] = []
}

struct VolumeState {
    var volumes: [VolumeInfo] = []
}

And my reducers are:

func appReducer(action: Action, state: AppState?) -> AppState {
    return AppState(
        modelState: modelReducer(action: action, state: state?.modelState),
        volumeState: volumeReducer(action: action, state: state?.volumeState))
}
        
func modelReducer(action: Action, state: ModelState?) -> ModelState {
    var state = state ?? ModelState()
    
    switch action {
    case let action as SetModel:
        state.model = action.model
        state.model?.usbPortsLeft.enumerated().forEach { (index, portNumber) in
            state.ports.append(Port(portNumber: portNumber, state: .unknown, area: .left))
        }
        state.model?.usbPortsRight.enumerated().forEach { (index, portNumber) in
            state.ports.append(Port(portNumber: portNumber, state: .unknown, area: .right))
        }
        state.model?.usbPortsBack.enumerated().forEach { (index, portNumber) in
            state.ports.append(Port(portNumber: portNumber, state: .unknown, area: .back))
        }
    default: break
    }
    
    return state
}

func volumeReducer(action: Action, state: VolumeState?) -> VolumeState {
    var state = state ?? VolumeState()
    
    switch action {
    case let action as AddVolume:
        if let volumeInfo = action.volume {
            state.volumes.append(volumeInfo)
        }
    case let action as RemoveVolume:
        if let basePath = action.basePath {
            state.volumes.removeAll(where: { $0.volumePath == basePath })
        }
    default: break
    }
    
    return state
}

The SetModel action is only called twice during startup. So I assume that "ports changed" is only printed twice (see func newState in the PortWindowService class). But even when the actions AddVolume or RemoveVolume are called in a different reducer, in a different sub-state, which is not selected during subscription in the StoreSubscriber initialization, I'll get an event and newState is called.

What am I missing here? How can I make sure that with store.subscribe(self) { $0.select { $0.modelState } } newState is only called when anything in modelState changes, but not in volumeState?

• [X] bumped Xcode marketing version
• [X] bumped CocoaPod version
• [ ] Add release date to the changelog when merging

Edit: Motivation: to release a Swift 5.7[.1] binary with recent changes.

For example, when you have UserState in ViewControler that displays a user and posts, what is the best practice to do?

• UserViewController -> UserViewController -> UserViewController...
• UserViewController -> PostViewController -> UserViewController -> PostViewController...

struct UserState: Equatable {
    var user: User
    var posts: [Post] = []
}

Can I implement something like below?

struct AppState: Equatable {
    // var user = UserState()
    var users: [UserState] = []
}

I am new to ReSwift and would appreciate any advice you could give me :bow:

We have several actions that are chained one after another in this manner:

1. Action is dispatched
2. A StoreSubscriber receives newState callback on state change
3. It dispatches another Action on the same Store
4. Another StoreSubscriber (or maybe the same one) receives newState callback on state change
5. It dispatches another Action on the same Store

These chains are not infinitely recursive, their depth is 2-4 actions. They all operate on single (main) thread synchronously. We see a crash when 2nd or 3rd dispatch is called inside ReSwift. It occurs with different action sequences. One case we can reproduce 100% in debug configuration (-Onone), but it's not reproduced in release configuration.

Stacktrace top is __swift_instantiateConcreteTypeFromMangledName

First of all, huge thanks for creating and maintaining ReSwift; it’s a pleasure to use!

I noticed a big CPU gap between ReSwift Store vs just a SwiftUI ObservableObject:

ReSwift Store: 23-28% CPU SwiftUI ObservableObject: 4-5% CPU

Tested on iPad Pro, 11 inch, running iPadOS 16.1.1 (20B101).

My app uses DisplayLink’s .onFrame to perform certain actions on each frame: https://github.com/timdonnelly/DisplayLink

Interestingly, I had benchmarked this in ~Feb 2021 on ReSwift version 6.0.0 and had a much better CPU, e.g. ~6-7%.

Currently, I get better perf on the older versions with StateType conformance:

• 6.0.0: 16-19%
• 5.0.0: 17-18%

Is this expected, or am I using ReSwift incorrectly? What could account for such a big perf difference?

Relevant code below. Also, repo with sample project: https://github.com/pianostringquartet/ReSwiftPerfTest/blob/main/PerfTestApp/ReSwiftPerfPlay.swift

//
//  ReSwiftPerfTest.swift
//
//  Created by Christian J Clampitt on 11/23/22.
//

import SwiftUI
import ReSwift
import DisplayLink

//@main
//struct MyApp: App {
//    var body: some Scene {
//        WindowGroup {
//            ReSwiftPerfPlay()
//        }
//    }
//}

class ObservableData: ObservableObject {
    var counter = 0
}

struct ReSwiftState: StateType, Equatable {
    var counter = 0
}

struct ReSwiftPerfPlay: View {

    @StateObject var observableData = ObservableData()
    @StateObject var storeData = ReSwiftStore<ReSwiftState>(store: reswiftStore())

    var body: some View {
        Text("UI does not use state")
            // DisplayLink: on-frame callback:
            // https://github.com/timdonnelly/DisplayLink
            .onFrame { _ in

                // When updating `observableData` alone,
                // CPU is 4-5%
//                observableData.counter += 1

                // When updating `storeData` alone:
                // ReSwift 6.1.0: CPU is 23-28%
                // ReSwift 6.0.0: CPU is 16-19%
                // ReSwift 5.0.0: CPU is 17-18%
                storeData.dispatch(CounterIncremented())
            }
    }
}

// -- MARK: reducer, store, action

func reswiftReducer(action: Action,
                    state: ReSwiftState?) -> ReSwiftState {
    var totalState = state ?? ReSwiftState()

    if action is CounterIncremented {
        totalState.counter += 1
        return totalState
    } else {
        return totalState
    }
}

struct CounterIncremented: Action, Equatable { }

func reswiftStore() -> Store<ReSwiftState> {
    Store<ReSwiftState>(reducer: reswiftReducer,
                        state: ReSwiftState())
}

// -- MARK: adapting ReSwift to SwiftUI

typealias Dispatch = (Action) -> Void

class ReSwiftStore<T: StateType>: ObservableObject {
    private var store: Store<T>

    @Published var state: T

    let dispatch: Dispatch

    init(store: Store<T>) {
        self.store = store
        self.state = store.state

        let dispatch: Dispatch = store.dispatch
        self.dispatch = dispatch

        store.subscribe(self)
    }

    deinit {
        store.unsubscribe(self)
    }
}

extension ReSwiftStore: StoreSubscriber {
    public func newState(state: T) {
        DispatchQueue.main.async {
            self.state = state
        }
    }
}