Modeling substate as an enum with associated values

[rzulkoski]

I have a Todo list screen that is split into 3 reducers:

1. TodoList reducer (screen-level)
2. TodoListContent reducer
3. TodoListRow reducer

My TodoList.State has a loadingState property on it where LoadingState is defined as:

/// Represents the different states of a piece of loadable substate.
public enum LoadingState<LoadedState, LoadError>: Equatable where LoadedState: Equatable, LoadError: Equatable, LoadError: Error {
  /// Substate has not yet been loaded.
  case notLoaded

  /// Substate is in the process of being loaded.
  case loading

  /// Substate has successfully loaded.
  case loaded(LoadedState)

  /// Substate has failed to load.
  case failed(LoadError)
}

In this instance, the LoadedState is TodoListContent.State.

I'm in the process of migrating these reducers to the ReducerProtocol and have encountered a large degradation in performance. After using some of the debugging tools available on WithViewStore, I have determined that any time the associated value (LoadedState) changes the parent view is recreating a new content view. This makes sense because the previous value of the loadingState property is no longer equal to the new value.

I was able to work around this issue by manually adding the equality conformance and ignoring the associated values like so:

public enum LoadingState... {
  ... // *snip

  public var discriminator: Discriminator {
    switch self {
    case .notLoaded: return .notLoaded
    case .loading: return .loading
    case .loaded: return .loaded
    case .failed: return .failed
    }
  }

  public enum Discriminator: String, CaseIterable {
    case notLoaded, loading, loaded, failed
  }

  public static func == (lhs: Self, rhs: Self) -> Bool {
    lhs.discriminator == rhs.discriminator
  }
}

So here's my question: Is this a reasonable workaround for the issue I was encountering or is there a different tool I should be reaching for here?

[stephencelis]

@rzulkoski I think we need a little more context and code to debug the issue, but glad you found a workaround!

I'm in the process of migrating these reducers to the ReducerProtocol and have encountered a large degradation in performance

I'm not quite sure I understand how migrating to the ReducerProtocol would introduce performance degradation at the view layer. Did you make changes to the view as well?

TCA provides SwitchStore precisely to work around the problem of enum state performance in SwiftUI by limiting updates based on the enum tag:

swift-composable-architecture/Sources/ComposableArchitecture/SwiftUI/SwitchStore.swift

Line 176 in 3bfbc7f

return WithViewStore(store, removeDuplicates: { enumTag($0) == enumTag($1) }) { viewStore in

Are you using SwitchStore?

[rzulkoski]

What's the best way to have access to the view store from modifiers on a view without wrapping the view itself? Looking at the view code above you'll notice that I make no references to viewStore within LoadableView or its contents.

[rzulkoski]

Upon further investigation, I've determined a few things:

1. Adding the manual conformance to Equatable did NOT actually fix my problem.
2. Creating a TodoListView.ViewState did address the issue where the TodoListContentView was getting recreated way more than was necessary.
   • Although it was a bit awkward to include bindings (Thanks @tgrapperon for this helper!)
3. The real issue that was causing the strange behavior that I was seeing is that my list code is organized like this:

public var body: some View {
  WithViewStore(self.store) { viewStore in
    List {
      Section {
        ForEachStore(self.store.scope(state: \.todos, action: TodoListContent.Action.todoRow(id:action:)) { rowStore
          TodoListRowView(store: rowStore)
        }
      } footer: {
        // Some view for representing loading more, failure to load more
      }
    }
    .listStyle(.grouped)
  }
}

Any time the footer needed to be refreshed, it would recreate the entire section. Is there any way around this when using Section? Or should I just break this up into separate views? I did like this strategy for consistently looking good across different list styles.

[fabstu]

@tgrapperon opened a discussion about such Section being refreshed in #1595, even when it does not use the outer viewStore. StoreIsolated might be useful, but haven't tried it yet. It also has some drawbacks.

I think this is still a weakness of TCA, but not sure whether it can be fixed in a cleaner way (ObservedObject has the habit of otherwise refreshing the whole view body).

[rzulkoski]

Thanks for the response @fabstu, although I think this situation is a bit different. I'm specifically referring to Apple's SwiftUI.Section. My hunch is that when any of the generic views changes, such as the Footer, the entire Section view is recreated.

[rzulkoski]

Okay, I've peeled back another layer of the onion. It appears that Section is only misbehaving because my footer is a Group conditionally containing different views:

} footer: {
  Group { // <--- Wrong, don't do this!
    if someCondition {
      ViewA()
    else {
      ViewB()
    }
  }
  .someSharedModifiers()
}

If I replace the Group with a VStack, the issue where the entire Section is recomputed goes away.