Computed child state with SwitchStore / IfCaseLet

[natemann]

it seems common practice to have a child state as a computed property to update a parent's property. Is the possible when the child state is part of a SwitchStore. For Example:

public struct Parent: ReducerProtocol {

  public struct State: Equatable {
    var section: SectionState
    var service: Service
    var tabList: TabList.State

    var childState: child.State? {
      get {
        guard case .child = tabList.selectedTab else { return nil }
        return .init(service: service)
      }
      set {
        // This never gets called
        guard let newValue else { return }
        service = newValue.service
      }
    }
  }

  enum Action {
    case section(SectionAction)
   case tabList(TabList.State)
  }

  enum SectionState: Equatable {
    case child(Child.State)
  }

  enum SectionAction: Equatable {
    case child(Child.Action)
  }

  public var body: some ReducerProtocol<State, Action> {
    Scope(state: \.tabList, action: /Parent.Action.tabList) {
      TabList()
    }

   EmptyReducer()
     .ifCaseLet(/SectionState.child, action: /SectionAction.child) {
       Child()
    }

  Reduce { state, action in 
   //...
 }
}

The set never gets called when childState is updated. My guess is because IfCaseLet in the Reducer uses CasePath instead of a theoretical WritableCasePath. Is this correct, or is there a way I can get set to be called?

[stephencelis]

@natemann Can you post a full, working example with steps to reproduce the problem? So long as the value type is being updated through that property, it should be observable, but maybe we're missing a piece of the puzzle.

[natemann]

@stephencelis here you go
https://github.com/natemann/SwitchStoreBug

[natemann]

@stephencelis start app, press 'child' button, then press 'increment'. I would think the parent number should change to the child's value, but it does not

[JackYoustra]

I think that this is modifying the wrong thing? You shouldn't have

EmptyReducer()
     .ifCaseLet(/SectionState.child, action: /SectionAction.child) {
       Child()
    }

as childState always exists.
You probably want something like

EmptyReducer()
     .ifLet(\.childState, action: /SectionAction.child) {
       Child()
    }

Here, you're directing the ifLet to use childState instead of the setter for the property directly

[natemann]

@JackYoustra I'm not following your solution. I can't even get your suggestion to compile

[JackYoustra]

Oh yeah sorry I’m not sure what the precise syntax is this is more of an outline

[tgrapperon]

Hey @natemann! Your sample is not working because no reducer is working on State.child: Child.State?, so the setter part of the computed property will only be hit when you assign it manually.

I must admit that your model is a little exotic and there are probably less intricate ways to achieve what you're looking for. I guess we can inverse the priority hierarchy. The number that is stored in State is the lower-level value (in the sense of "closer to the root"). Then child: Child.State? that depends on number, and then section.child(Child.State) that depends on child. So we can try to reorganize the values. In any case, if you define a computed property for a child feature, it should be coherent: if you extract a value in the getter, you should reinject it in the setter. Otherwise, changes performed by the reducer working on this state will not be properly propagated/persisted into the model. In your case, you can for example rewrite your domain as:

struct Parent: ReducerProtocol {
  enum Tab: Equatable {
    case child
    case other
  }

  struct State: Equatable {
    init(
      number: Int,
      selectedTab: Parent.Tab,
      section: Parent.SectionState,
      child: Child.State? = nil
    ) {
      self.number = number
      self.selectedTab = selectedTab
      self.section_ = section
      self.child_ = child
    }
    
    var number: Int
    var selectedTab: Tab

    // Some private storage for the `SectionState` value 
    // (used when the case is `other` in this example)
    private var section_: SectionState
    var section: SectionState {
      get {
        if let child = self.child {
          return .child(child)
        }
        return self.section_
      }
      set {
        if case let .child(child) = newValue {
          self.child = child
        }
        self.section_ = newValue
      }
    }

	// Private storage that stores a fully fledged `Child.State?` to keep
    // other `Child.State` properties than `number` (here, there are none,
    // but I'm implementing it as if it wasn't the case).
    private var child_: Child.State?
    var child: Child.State? {
      get {
        // Pick the private storage:
        var child = self.child_
        // Inject self.number:
        child?.number = self.number
        // Return the updated value:
        return child
      }
      set {
        // Save the new `Child.State?` in the private storage:
        self.child_ = newValue
        if let newValue {
          // Extract self.number:
          self.number = newValue.number
        }
      }
    }
  }

  enum Action {
    case section(SectionAction)
    case select(Tab)
  }

  enum SectionState: Equatable {
    case child(Child.State)
    case other(Other.State)
  }

  enum SectionAction {
    case child(Child.Action)
    case other(Other.Action)
  }

  var body: some ReducerProtocol<State, Action> {
    Scope(state: \.section, action: /Action.section) {
      // Alternative to `EmptyReducer().ifCaseLet().ifCaseLet()…`
      Scope(state: /SectionState.child, action: /SectionAction.child) {
        Child()
      }
      Scope(state: /SectionState.other, action: /SectionAction.other) {
        Other()
      }
    }

    Reduce { state, action in
      switch action {
      case .section:
        return .none

      case .select(.child):
        state.selectedTab = .child
        state.section = .child(.init(number: state.number))
        return .none

      case .select(.other):
        state.selectedTab = .other
        state.section = .other(.init(number: 0))
        return .none
      }
    }
  }
}

And this reducer updates the parent value as expected. Please note that I'm underscoring private values with a trailing underscore because it composes more nicely with property wrappers (that are already using a leading underscore for the wrapped storage) and with CoreData (that prohibits values starting with an underscore). But you can of course use a leading underscore (or whatever convention) to denote private storage.

Of course, this example can be simplified by removing the child_: Child.State? private storage that is not required here, as child can completely be rebuilt from self.number and self.section_

One alternative would be to remove the reducer from Section.child and use an optional Child reducer working on self.child: Child.State?:

Reduce { … }
  .ifLet(\.child, action: /Action.section .. /SectionAction.child) {
    Child()
  }

but it forces us to compose CasePaths and it breaks the symmetry with SwitchStore. But because Section.child and child: Child.State? are tightly bound, it would work the same. Again, not something to do, but you can try to check that it effectively works when working on child: Child.State? "by proxy".

[natemann]

@tgrapperon My app actually has 10 cases, all of which get passed the same object, and needs to pass this value back up to the parent. I do not see your first solution as a good choice as it would be overly verbose. The second solution only works 'half-way' This ifLet reducer updates the parent, but not the child. It seems that I need both reducers. The CaseLet to update the child, and the IfLet to update the parent.

I might just have to refer to Delegate Actions to pass the value back up to the parent.

[tgrapperon]

I have such setups, and this is not the end of the world. Your enum is a computed property and you inject the shared value in get, and extract it back in set. It works well, and it takes ~50 lines to get it done once and for all, which is not uncommon when you're yielding 10-cases enums. The example I proposed was a little contrived because it was based on your sample case where you expected the shared state to be an active domain by itself. The situation you're describing seems simpler to implement, as you would only have reducers working on the enum's cases. They would just happen to get and update a coherent piece of shared state thanks to the computed property.

You can also synchronize with reducers as you plan to do, but you'll probably have to perform more or less the same work as you would do in the computed enum's accessors, and you will depend on the reducers effectively running for your model to be in a coherent shape (which is not an issue per se, but weaker than computed properties). I've experimented with generalizations of this procedure in the past, but there are many sharp edges (like the model possibly breaking invariants if the reducer doesn't run as I mentioned). I plan to revisit it after the version 1.0 is released.

[iampatbrown]

@natemann if your goal is for the number property to update with the child state, it might be something you can handle in the parent reducer.

Reduce { state, action in
  switch action {
  case .section:
    if case let .child(childState) = state.section {
      state.number = childState.number
    }
    return .none

  case .select(.child):
    state.selectedTab = .child
    state.section = .child(.init(number: state.number))
    return .none

  case .select(.other):
    state.selectedTab = .other
    state.section = .other(.init(number: 0))
    return .none
  }
}

The OnChange reducer from isowords might work for you in some cases too. Here's an example where it's being used to update state.

[tgrapperon]

For the sake of completeness, and in the case where each enum's case simply hosts a shared bit of data, the computed property I was proposing would take the general form:

struct State {
  struct Shared {
    var count = 12
  }

  struct S1 {
    var shared: Shared = .init()
    …
  }

  struct S2 {
    var shared: Shared = .init()
    …
  }

  struct S3 {
    var anotherShared: Shared = .init()
    …
  }

  enum Section {
    case s1(S1)
    case s2(S2)
    case s3(S3)
  }
  
  // Properties
  var shared = Shared()
  
  private var _section: Section = .s1(.init())
  var section: Section {
    get {
      var section = self._section
      switch section {
      case var .s1(s1):
        s1.shared = self.shared
        section = .s1(s1)
      case .s2: // Alternative, using a `CasePath`
        try! (/Section.s2).modify(&section) { $0.shared = self.shared }
      case var .s3(s3):
        s3.anotherShared = self.shared
        section = .s3(s3)
      }
      return section
    }
    set {
      self._section = newValue
      switch newValue {
      case let .s1(s1):
        self.shared = s1.shared
      case let .s2(s2):
        self.shared = s2.shared
      case let .s3(s3):
        self.shared = s3.anotherShared
      }
    }
  }
}

This is not nice, but it scales relatively OK. Of course, you can pair with Pat's OnChange suggestion or some ad hoc reducer to propagate the changes higher if this is not automatically performed by a chain of computed properties.

[natemann]

@tgrapperon @natemann thank you for all your help. I actually did try the onChange reducer from isowords, and it does work. I was just thinking computed properties could be short and simple.