App Architecture State Question about episode-code-samples

[mbrandonw]

Hey @natemann, you are correct that we want all of our state mutations happening in the reducer, but we feel that this is a bit different.

This more akin to "glue" code, or you could call it "adapter" code. The AppState struct contains a lot of fields, but we only want to share a few of those fields with the counter view. So, we create a custom computed property that shows how to project out the fields we care about (in the get), and how to plug those fields back into the app state (in the set).

This is mostly logic-less work, and that's why we feel it's different from the kind of state changes that happen inside a reducer.

Does that make sense?

[natemann]

@mbrandonw. Thanks. I understand the get, the ‘set’ seems necessary for the pullback operation. But even then, you have setters for both the state and the action, so it seems like the state may be getting mutated twice? I have not tested this though. It seems that the pullback is the only time the set will actually be called for either the state of the action.

Let’s say we didn’t have the pullback, but only had a setter for the action (or vice versa). I believe the AppState will still be mutated at the appropriated times.

[mbrandonw]

You are right that the set, and really the whole computed property, is only necessary for the pullback. We need it to get access to the key path that we pull back along.

The app state is not mutated twice though. We extract out a subset of state, CounterViewState, hand it over to the counter reducer to mutate, and then we plug CounterViewState back into AppState. So the app state is only mutated a single time in that situation.

Does that clear things up?

[natemann]

Yep... that’s makes since. I have been using RxSwift and pure functions for the ViewModel. I like this approach to standardize the architecture ,especially for SwiftUI, but it seems overly verbose at times.

[natemann]

So appstate is mutated when counterstate gets plugged back in, through the set, but we are also updating the Appaction through the CounterAction. This is where I thought perhaps mutation was happening twice.