Mutating parent on child mutations

[av0c0der]

I was struggling with some unnecessary mutations happening in the parent view when child view state changed. Then I found out that one of the CaseStudies has the same behaviour and I wonder how I can workaround it.

In Case Study 03. Navigation Sheet Present and Load on each optionalCounter update the PresentAndLoadView and CounterView both will be recreated.

Speaking about this particular example: is it possible to prevent PresentAndLoadView from recreating on each mutation of its child (CounterView sheet)? I only want CounterView to update its state on increment/decrement action, but not the PresentAndLoadView.

[abdelmajidrajad]

From my understanding of pointFree Episodes, I could say that composable architecture solve this problem by having all your struct conforms to Equatable protocol and having ViewStore on Each View.

[av0c0der]

Thank you very much for your answer. I saw some responses to similar questions here while looking for a solution, but it seemed impossible for my situation to wrap that up to a scope and also have this plugin type reducer so it will produce events in the parent reducer too. The key here is View Store. I introduced this concept into the parent view and it solved my problem.

[mbrandonw]

Yeah it is possible. I believe what @abdelmajidrajad is referencing is that we should probably update this line:

swift-composable-architecture/Examples/CaseStudies/SwiftUICaseStudies/03-Navigation-Sheet-PresentAndLoad.swift

Line 64 in 9e50df4

WithViewStore(self.store) { viewStore in

To chisel away the state to exactly what is needed in the view. So something like:

WithViewStore(self.store.scope(state: \. isSheetPresented)) { viewStore in 
  ...
}

Then the view would re-compute itself only when the sheet is presented or dismissed.

[RabugenTom]

Maybe it would be worthwhile to make a simple case study where you're using a dedicated "ViewState", like you seem to do in isowords.

struct MyView: View {
  let store: Store<State, Action>

  struct ViewState: Equatable {
    let bool: isPresented
    init(_ state: State) {
      isPresented = state.isPresented
    }
  }

  var body: some View {
    WithViewStore(store.scope(state: ViewState.init)) { viewStore in
      …
    }
  }
}

When I first started to use TCA, I was afraid to put too much things in my states because I didn't really understand what happens when things are changed. I was convinced that touching my state on some leaf would trigger heavy states comparisons everywhere, until I understood that states are never equated if you don't ask them too! There is no state comparison in Store, only in the ViewStore, and only with what you give it, and you don't need to give it more than needed to display a specific view.

I think my initial confusion comes from not understanding that scoping can be used for different purposes: you can scope sub-stores to pass them to sub-features, but you can also scope them as a smaller store to pass to a ViewStore to ease comparison. Maybe a case study with an heavy state, possibly un-equatable in its whole, would make this clearer to newcomers.

[av0c0der]

Thank you @mbrandonw for the answer and @RabugenTom for going deep into the topic and the proposal, I also think it will be great.

(I was thinking which answer to accept, I think what @abdelmajidrajad said fits best and @mbrandonw answer shows some code and will get attention anyway)