Performance impact of computed property

[marcuswu0814]

According to Doc - Performance/Store Scoping, I know about the scoping child store of computed property will trigger computed every time when parent state changed.

In our development context, the existing class ViewModel/ViewController using RxSwift/RxCocoa/RxCombine to bind the data into view.

We have a helper function like:

import RxCombine
import RxSwift
extension Store {
    func toObservable<ViewState: Equatable>(
        _ toViewState: @escaping (State) -> ViewState
    ) -> Observable<ViewState> {
        ViewStore(self, observe: toViewState)
            .publisher
            .asObservable() // Just let store's publisher be `Observable`
    }
}

The ViewModel and ViewController like:

class ViewModel {
    let time: Observable<String>
    let a: Observable<String>
    let b: Observable<String>
    let aPlusB: Observable<String>
    let store: StoreOf<Feature>
    
    init() {
        store = .init(initialState: .init()) {
            Feature()
        }
        
        time = store
            .toObservable(\.seconds)
            .map { String($0) }
        a = store
            .toObservable(\.a)
            .map { String($0) }
        b = store
            .toObservable(\.b)
            .map { String($0) }
        aPlusB = store
            .toObservable(\.aPlusB)
            .map { String($0) }
        store.send(.start)
    }
    
    deinit {
        store.send(.end)
    }
}

class ViewController: UIViewController {
    // ...
	override func viewDidLoad() {
		// ...
	 	viewModel.a
            .bind(to: aLabel.rx.text)
            .disposed(by: disposeBag)
		// ...
	}
}

And the Reducer like:

@Reducer
struct Feature: Reducer {
    
    struct State: Equatable {
        var seconds = 0
        @BindingState var a = 0
        @BindingState var b = 0
        var aPlusB: Int {
            print("🥸 Computed")
            return a + b
        }
    }
    
    enum Action: BindableAction {
        case binding(BindingAction<State>)
        case start
        case end
        case timerTicked
    }
    
    @Dependency(\.continuousClock) var clock
    
    private enum CancelID { case timer }
    
    var body: some Reducer<State, Action> {
        BindingReducer()
        Reduce(core)
    }
    
    private func core(_ state: inout State, action: Action) -> Effect<Action> {
        switch action {
        case .start:
            return .run {send in
                for await _ in self.clock.timer(interval: .seconds(1)) {
                    await send(
                        .timerTicked,
                        animation: .interpolatingSpring(stiffness: 3000, damping: 40)
                    )
                }
            }
            .cancellable(id: CancelID.timer, cancelInFlight: true)
            
        case .end:
            return .cancel(id: CancelID.timer)
            
        case .timerTicked:
            state.seconds += 1
            
        case .binding:
            break
        }
        
        return .none
    }
    
}

The full executable project is here, and my questions is:

Q1: Is ViewStore(observe:) kind of scoping child state?

The above code I wrote is straightforward for transform a state into observable, but current concern is, the computed property will be trigger by timerTicked action and the state changed. So should I avoid this strategy for my use cases?

Q2: If I refactor computed property into mutating function, is the following code best practices?

I try to improve the recalculate, using a mutating function for State like:

@Reducer
struct Feature: Reducer {
    struct State: Equatable {
        var seconds = 0
        @BindingState var a = 0
        @BindingState var b = 0
        var aPlusB = 0
        mutating func caculate() {
            aPlusB = a + b
        }
    }
    // ...
    var body: some Reducer<State, Action> {
        BindingReducer()
            .onChange(of: \.a) { _, _ in
                Reduce { state, action in
                    state.caculate()
                    
                    return .none
                }
            }
            .onChange(of: \.b) { _, _ in
                Reduce { state, action in
                    state.caculate()
                    
                    return .none
                }
            }
        Reduce(core)
    }
}

But:

1. The boilerplate onChnage(of:) modifier their and should remember to invoke state.caculate().
2. If the computed logic is not just a and b, should include c or d, the modifier much more redundant, is there have any advance for this situation?

[marcuswu0814]

@mbrandonw Soory to bother you, will version 1.7 enhance this use case?

[mbrandonw]

Hi @marcuswu0814, sorry I did not see this before. I'm not sure I understand the question. The doc you linked to is only relevant for performing scoping via a computed path, i.e. store.scope(state: \.computedField, …). And further, this is only problematic if computedField does a lot of work.

But, if you are just using a computed property on state in your view, as is the case of aPlusB of your demo app, then a computed property is just fine.

Does this help?

[marcuswu0814]

My primary concern is, the timer tick every second and mutate the state, the computed property will re-calculate each time.

If the computed property is not heavy work, I know it’s ok to use.

But in my real use case, I do some heavy work in mutating func calculate() function, and it’s not just a and b, maybe need more state filed.

// Old way

let calculatedState = Observable
  .combineLatest(a, b, c, d, e)
  .map { // ... } 

// With mutating function

@Reducer 
struct Feature: Reducer {
  struct State: Equatable {
    var seconds = 0
    @BindingState var a = 0
    @BindingState var b = 0
    @BindingState var c = 0
    @BindingState var d = 0
    @BindingState var e = 0
    var calculatedState = 0
    mutating func caculate() {
      // Fake work
      calculatedState = a + b * c / d - e
    }
  }
    // ...
  var body: some Reducer<State, Action> {
    BindingReducer()
      .onChange(of: \.a) { _, _ in
        Reduce { state, action in
          state.caculate()
              return .none
        }
      }
      .onChange(of: \.b) { _, _ in
        Reduce { state, action in
          state.caculate()
          return .none
        }
      }
      // <- ❗️ If I forgot to add observe for `c`, `d`, `e`, the `calculatedState` would be wrong.
      // ✅ But in this pattern, no performance impact.`

      Reduce(core)
  }
}

// With computed property

@Reducer 
struct Feature: Reducer {
  struct State: Equatable {
    var seconds = 0
    @BindingState var a = 0
    @BindingState var b = 0
    @BindingState var c = 0
    @BindingState var d = 0
    @BindingState var e = 0
    var calculatedState: Int {
      // Fake work
      return a + b * c / d - e
      // ❗️ Some heavy work may impact CPU loading if every second run cause by seconds changed.
      // ✅ But in this pattern, I don't need to observe every change and remember to invoke `caculate()`
    }
  }
}

I need a robust way to do job in this situation, any tips for it?

I’m so sorry about not major in English, if anything need more information, please let me know. 🙇🏿‍♂️

[mbrandonw]

Hi @marcuswu0814, this is just a problem of SwiftUI in general, and not really a TCA problem. When a view re-computes its body it needs access to all state to render, and so that forces your computation to run. I don't think there's any magic solution to this problem.

One other alternative is calculate the computed state in a didSet of each property:

struct State {
  var seconds = 0
  var a = 0 { didSet { calculate() } }
  var b = 0 { didSet { calculate() } }
  var c = 0 { didSet { calculate() } }
  var d = 0 { didSet { calculate() } }
  var e = 0 { didSet { calculate() } }
  var calculatedState = 0
  mutating func caculate() {
    calculatedState = a + b * c / d - e
  }
}

This is definitely better than the onChange style of calculating the state, but it still has pros and cons compared to just computed the data fresh in the view.

[marcuswu0814]

I think I try to avoid property observe previously because of this tip about testability, I will try it later, thanks for your quick response and help. 🙏