How to pass a subset of state to a substore

[ivangodfather]

Lets make a quick example with "pseudo" code

struct User {
  let username: String
}
struct AppState {
   var user: User?
   var updateUser = UpdateUserState()
}
enum AppAction {
   case updateUser(UpdateUserAction)
}
struct UpdateUserState {
  var username = ""  // this would be binded to a TextField
}
enum UpdateUserAction {
    case performRequestToUpdateUser(username)  // this will call environment.updateUserEffect(username).map(UpdateUserAction.updatedUser)
     case updatedUser(User)
}

When I present the UpdateUserView I do something in these lines...

UpdateUserView(
	store: store.scope(
		state: \.updateUser,
		action: AppAction.updateUser
	)
)

I certainly get the updated user from the "appReducer" (not declared here) by simply:

case .updateUser(.updatedUser(let newUser)):
  state.user = newUser

But how I'm supposed to pass the user to the "UpdateUserView" for example to prefill the textField with the existing one from AppState?

[tgrapperon]

Hello @ivangodfather!
As often, there are several ways to achieve this.
The most common is to rely on a computed property that is updated on "get" and reinjected on "set". So, with your current model:

extension AppState {
  var updateUser: UpdateUserState {
    get {
      UpdateUserState(username: user.username)
    }
    set {
      self.user.username = newValue.username
    }
  }
}

This is more foolproof than having to account for each possible username modification.
Using this setup, a whole new UpdateUserState is delivered each time. It furthermore frees one stored field from your AppState which is always a good thing (faster automatic equatability, smaller footprint on the stack, etc.)
But this approach needs to be slightly adapted when your child state has internal or unrelated fields. For example, if your UpdateUserState is

struct UpdateUserState {
  var username = ""
  var cursorPosition: CGPoint?
}

you will lose the cursorPosition value each time the state is extracted from AppState. The usual workaround is to use a private storage for UpdateUserState, and update this storage when the property is accessed/reinjected:

struct AppState {
  private var _updateUser: UpdateUserState = .init()

  var updateUser: UpdateUserState {
    get {
      var value = _updateUser
      value.username = user.username
      return value
    }
    set {
      _updateUser = newValue
      self.user.username = newValue.username
    }
  }
  …
}

This method is general, and can apply to almost all cases, but it could be not performant enough when your child state is a large collection. If performance is problematic, you can then either:

• watch for actions that are susceptible to change the User in AppState, and update your child state accordingly, as you suggested.
• watch the user value directly if it is Equatable, and update the child state only when it changes. This can be conveniently achieved using some higher-order reducer similar to onChange from isowords. In this case, you only have to tap .onChange at the end of your appReducer:

let appReducer = Reducer<…> {
  …
}
.onChange(\user.username) { newValue, state, action, environment in
  state.updateUser.username = newValue
}

Each method has its pros and cons, and you may have to switch from one to another as your app evolves and you hit their own limitations. There is no silver bullet to my knowledge.

[ivangodfather]

@tgrapperon thank you! Let me go over the PR. There is no issue on my side, just wanted to show how I "solved" my own issue and wanted to double check with you that I was not doing anything super wrong.

[ivangodfather]

Everything makes a lot of sense besides adding the "username" into the initializer. If so, I would rather call it "placeholder" so the caller is aware what that actually is (he can put whatever wants there), whereas using my approach I set privately the placeholder always to the username.

[tgrapperon]

The placeholder can also be something you only display in the UI when userName is empty.
But I'm glad it helped. In this specific case, I would personally use non-optional Users, and a computed property with private storage for updateUser state:

var user: User
var _updateUser: UpdateUserState?

var updateUser: UpdateUserState? {
  get {
    guard var value = _updateUser else { return nil }
    value.user = user
    return value
  }
  set {
    _updateUser = newValue
    if let newValue = newValue {
      user = newValue.user
    }
  }
}

In this way, there is only one source of truth: the app's User, and you don't have to remember to update its value in the app's reducer when you receive some .updateUser action. You need private storage because the isLoading value need to be stored somewhere, but your UpdateUser feature always receives an up to date value for User.

[ivangodfather]

@tgrapperon I have a question regarding this last code (I saw also in your previous example), wouldnt the "set" block be called each time you modify any property of the state inside UpdateUserState ? like when you are setting state.isLoading = false. So you'll be updating the user even if you are only interacting with the view (like updating the textfield, if this view has toggles, etc...).

[tgrapperon]

Yes, it is, and that's why it's important to carve-out the piece of state you want to observe in your ViewStores. I was very worried about this for a long time, but experience showed that it is not really an issue most of the time. And in cases it would matter, you can always fallback to the reducer being in charge of the state synchronization.