I'd like to discuss adding a property wrapper to TCA.

[alwaysblu]

Hello,

I implemented a property wrapper called AlwaysEquatable.

AlwaysEquatable property wrapper type that always returns true meaning the same value

when performing a comparison operation (==), even if the values ​​are different.

@propertyWrapper
public struct AlwaysEquatable<Value> {
  public var wrappedValue: Value

  public init(wrappedValue: Value) {
    self.wrappedValue = wrappedValue
  }
}

extension AlwaysEquatable: Equatable {
  public static func == (lhs: Self, rhs: Self) -> Bool {
    true
  }
}

This type can solve the problem of popping at a specific depth when using NavigationLink,

which occurs when the local state in the global state changes.

For example, if you write the code as below,

objectWillChange.send() of ViewStore will not be called

when the value of displayName or localState is changed.

struct LocalState { ... }

struct GlobalState {
  var digest = Digest.daily
  @AlwaysEquatable var displayName = ""
  var enableNotifications = false
  var isLoading = false
  var protectMyPosts = false
  var sendEmailNotifications = false
  var sendMobileNotifications = false
  @AlwaysEquatable var localState: LocalState
}

Experiment

This is a navigation experiment project. (branch -> pop_case)

The project is simple.

There is a 2 depth navigationLink in the first NavigationView

and a 2nd NavigationView which has a 3 depth navigationLink in the 2 depth navigationLink of the first NavigationView.

That is, a total of 5 depths.

And some depths each have a button to change the random state.

Case 1

This is a case where the AlwaysEquatable property wrapper is not applied.

For convenience, I will call these views root, depth 1, 2, 3, 4, 5

An unexpected problem arises here.

When the state of depth 2, 3, 4, 5 except for the state of depth 1 is changed, an unexpected pop occurs.

The initial value of random state is 0, and when the reset button is pressed, it is initialized to a random value between 0 and 100.

Case 2

This case, @AlwaysEquatable is applied only to depth3State,
which is a property of the state of Depth 2 where the second NavigationView exists.

struct Depth2State: Equatable {
  @AlwaysEquatable var depth3State: Depth3State
  var random: Int

  init(
    depth3State: Depth3State = .init()
  ) {
    self.depth3State = depth3State
    random = 0
  }
}

In this case, an unexpected pop occurs only when the reset button of depth 2 is clicked.

Case 3

This case, @AlwaysEquatable is applied only to depth1State,
which is a property of the state of Root where the first NavigationView exists.

struct RootState: Equatable {
  @AlwaysEquatable var depth1State: Depth1State

  init(
    depth1State: Depth1State = .init()
  ) {
    self.depth1State = depth1State
  }
}

In this case, an unexpected pop occurs only when the reset button of depth 4, 5 is clicked.

Unlike case 2, when an unexpected pop occurs, the screen is converted to depth 3 instead of depth 1.

Case 4

This case, @AlwaysEquatable is applied to depth1State, depth3State

struct RootState: Equatable {
  @AlwaysEquatable var depth1State: Depth1State

  init(
    depth1State: Depth1State = .init()
  ) {
    self.depth1State = depth1State
  }
}

struct Depth2State: Equatable {
  @AlwaysEquatable var depth3State: Depth3State
  var random: Int

  init(
    depth3State: Depth3State = .init()
  ) {
    self.depth3State = depth3State
    random = 0
  }
}

In this case, there is no unexpected pop.

Experiment conclustion

An unexpected pop can be prevented by applying the AlwaysEquatable property wrapper to the local state in the State where the navigationView exists.

---

I would like to discuss whether this property wrapper will be removed in the future,

If this property wrapper is added to the TCA.

Thank you

[tgrapperon]

Hello @alwaysblu!
Thanks for the suggestion, this is indeed a nice idea. I proposed a similar approach in #527, where I built the comparison relation from zero and by adding properties to check, whereas yours goes the other way, by omitting properties from a complete state.

Unfortunately, as convenient as they are, they both share the same issue: you can access by mistake a property that will not be effectively observed from your view, leading to disparities between your UI and your model. Your version is likely more resilient to this issue because you're starting from a complete state, so it is less likely to tap on the excluded property than to tap on some unaccounted new property with my proposal.

Given the way dynamicMemberLookup works in ViewStore, we can't prevent access to these properties in a convenient way.

Going back to the issue that motivated your wrapper, it could probably be alleviated by using a ViewState, that is a specific Equatable substate of your state that is only exposing what's necessary to display a given view. You don't even have to have an homogenous correspondance between views, and you can map an Optional<DepthState> to a Bool that is false or true if the optional is nil or not. This kind of construction is generally more resilient to this kind of glitches. You can see examples in isowords or in this repository by searching for the term ViewState if you weren't aware of them.

Because of its liability and the ViewState's workaround, I'm reserved about this property wrapper's introduction into the core library. It doesn't mean that the property wrapper is intrinsically bad, it means it has some sharp edges that require some precaution when used, and it is probably safer to keep it out of reach of a general audience for this reason. I'm also not a maintainer of this library, so this opinion is purely personal and non-binding.

I would also like to mention that there are some preliminary works around a better integration of Navigation in TCA. It is possible that new property wrappers will be introduced to model these specific states, and maybe yours will find its place more naturally at this moment, in this form or another.

[alwaysblu]

Hello, @tgrapperon

thanks for your comment!
sorry for the late reply
I have been very busy this week.

My motivation for creating this property wrapper is to prevent unwanted updates to the View when a specific State such as localState is changed.
it can be used when you intend the inconsistency between the view and the model you mentioned.

I think that the responsibility of preventing access to match the View and model you mentioned is the responsibility of the access control such as 'private', not the property wrapper. and I'm not sure if it's right to have a private value as a property in State.

Thanks for letting me know about the ViewState code.
I think that replacement using ViewState would be impossible.
because I ran into a problem with things like 'Binding', when I used ViewState

If a new navigation way comes out,
I don't think there is any place where this property wrapper must be used.
I think it will be deleted later if it is not used where it is essential.
and I'm concerned about the side effects that would result from blocking local state changes.

So I agree with you about adding this code to the library.

I would really appreciate it if you leave your opinion on my opinion again next time

Thank you

[tgrapperon]

No worries for the late reply. I agree that using TCA's binding() reducer with ViewState can be a little verbose if you want to do it rigorously. There are several approaches, as discussed in #769. I'm personally using a dedicated overload that allows to "jump over" the ViewState to make them work with the minimal effort from my side.
ViewStates, in one form or another, are a fundamental tool to use if you want to keep performance in control (more than bindings that can be replaced by couple of value/actions), and you should definitely consider narrowing what your ViewStore are observing. Of course, your property wrapper could help, with all the sharp edges mentioned above, but this should be optimally something that you do "constructively" instead of "destructively", that is by specifying only what you want to expose instead of what you don't want to compare.
Right now, the whole ViewState story happens like a regular scoping, but it's maybe possible to formalize/specialize them to this task and to make them a little more convenient to handle.