Handling ViewState transformations within the context of Observation

[acosmicflamingo]

With Observation being around the corner, ViewState's time in the spotlight is coming to an end, and I wonder whether it's a good idea to start thinking about how to handle the ViewState transforming capabilities going forward. The value I saw from using ViewState wasn't so much from it's ability to reduce the amount a store has to observe, but more from how it could translate a Store's state to one that has more meaning within a view's domain.

To use concrete examples, I think it makes much more sense for a MusicLibrary.State to just comprise a property like data: IdentifiedArray<Items> while ViewState would have a property like deleteSongsButtonHidden: Bool . Specifically, I always liked how I don't have to worry about anything view-specific in my reducer, but that I can just subscribe to viewStore.publisher.deleteSongsButtonHidden that I can then assign to deleteSongsButton.isHidden within my view controller. The transformation would come from here:

struct ViewState {
  var deleteSongsButtonHidden: Bool

  init(state: MusicLibrary.State) {
    self.deleteSongsButtonHidden = !state.data.isEmpty
  }
}

That way, in my view controller I don't have to care about the data property and in my reducer, I don't have to care about the deleteSongsButtonHidden property.

From what I've seen in the observation videos and PRs, the impression I have is that I would actually be doing something like this:

class ViewController: UIViewController {
  func setupBindings() {
    observe {
      deleteSongsButton.isHidden = !store.data.isEmpty
    }
  }
}

However, now I've lost the ability to test deleteSongsButton behavior (I have created my own tests that assert values from my ViewState). Of course, I could move this logic to my reducer, but it seems a bit silly that any time I am mutating state.data, I need to remember that I need to update the deleteSongsButtonHidden property as well. A solution to this could be to use computed properties, but I believe that this will not work well at all with Store caching or the @ObservableState macro. But even if it were manageable, doesn't the reducer's state now become so much more bloated?

What is the best way going forward in a post-Observation world that would allow me to keep my ability to test logic conducted within the view-domain, while minimizing adding view-specific bloat to my reducer's state?

[mbrandonw]

Hi @acosmicflamingo, you can still use ViewState in some sense. In your view you can define ViewState as well as an initializer to turn Feature.State into ViewState:

struct ViewState {
  let deleteSongsButtonHidden: Bool
  init(_ state: Feature.State) {
    self.deleteSongsButtonHidden = state.data.isEmpty
  }
}   

And then when observing in the controller:

class ViewController: UIViewController {
  func viewDidLoad() {
    observe {
      let viewState = ViewState(store.state)
      deleteSongsButton.isHidden = viewState.deleteSongsButtonHidden
    }
  }
}

The act of initializing ViewState will cause the view to observe any fields touched and so the observe closure will automatically be called when any of those fields change.

[acosmicflamingo]

Oh no!!! So ViewState is a non-starter because it seems so silly to have to execute a whole closure just because one thing changed in the reducer.

I guess a bloated Store.State is the lesser of two evils here. Are all computed properties problematic with the introduction of store caching? Or just when a store is being scoped in the computed property?

[mbrandonw]

Perhaps it would be best to wait until we have documentation on this tool before making any decisions. I think it is important to understand how it works, and currently it seems there are some misunderstandings. But my impression is that the ViewState approach is perfectly fine, or adding computed properties to your state for view-specific data.

[acosmicflamingo]

Perhaps the answer to the following question will help me understand what you're saying.

Forgetting Observability for a moment, is there a cost if a block of code is executed more than once, even if no mutation occurs within the function call? If an app called the following 2 or 10 times, isn't that a waste of resources as opposed to calling it just once?

func updateButton(_ text: String) {
  button.text = text
}

updateButton("LOL")
updateButton("LOL")
updateButton("LOL")

Or even just doing something like this (which means the program wouldn't add onto the stack):

button.text = "LOL"
button.text = "LOL"
button.text = "LOL"

If the answer is that executing the same 3 times is the same as 1 in terms of efficiency, I can understand. I can also understand if this over-optimizing is not worth it because you're only wasting a few clock cycles by reloading registers with the same data (or maybe the app is smart enough to check if the data is the same and would not do anything).

Or maybe executing that three times will reload a view if you are setting its text property with the same text (which may or may not involve calling a UIView's updateLayout function).

I'm just trying to avoid refreshing my views when I don't need to.

[mbrandonw]

If the answer is that executing the same 3 times is the same as 1 in terms of efficiency, I can understand.

Yes, mutating the text field of a button multiple times, even hundreds of times, is not a big deal. For simple properties of UI components, I would not worry about accidentally setting them a few times more than necessary.

But for things like reloadData(), that is something you do want to minimize. And so that should be in its on observe block�

[acosmicflamingo]

Thank you very much; that was the fundamental misunderstanding here.

Great! Then I'll go with using ViewState under one giant observe block in the majority of cases and in the few situations where I need to actually care about calling something intensive like reloadView, I'll move it to another observe block (that does NOT use ViewState). Woohoo!!!

[acosmicflamingo]

It looks like what exists in the tic-tac-toe example is a very clean approach that gives me the ViewState behavior I sought, without needing to worry about over-observing state changes: https://github.com/pointfreeco/swift-composable-architecture/blob/main/Examples/TicTacToe/tic-tac-toe/Sources/LoginUIKit/LoginViewController.swift#L148.

[atimca]

Hey there I have a question on the same exact topic. Advanced Strategies for State-to-ViewState Conversion in SwiftUI with TCA's New Observability Features

I deeply appreciate the point-free team's work on the Swift Composable Architecture (TCA) 🫶, especially the new Observability features. These enhancements raise questions on handling complex state-to-ViewState conversions in SwiftUI projects, especially considering bindings and avoiding boilerplate.

In our application, we face challenges with screens that have intricate states, represented by detailed viewStates mirroring the UI structure. This complexity is further amplified by direct 1-to-1 state-to-viewState mappings, which could potentially leverage TCA's bindings more effectively.

For context, here’s a simplified model of our setup:

struct BackendEntity { }

struct AppState: Equatable {
    var loadingState: LoadingState = .loaded(backendEntity)
    // Simplified for demonstration
}

struct ItemViewState: Equatable {
    let title: String
    let description: String
    // Other properties for UI representation
}

struct ComplexViewState: Equatable {
    let sections: [SectionViewState]
    let isLoading: Bool
    // More complex UI-related properties
}

// Example of a direct 1-to-1 mapping
extension ItemViewState {
    init(item: Item) {
        self.title = item.title
        self.description = item.description
    }
}

// Conversion from AppState to ComplexViewState, showcasing the complexity
extension ComplexViewState {
    init(state: AppState) {
        self.isLoading = (state.loadingState == .loading)
        self.sections = sections(from: state.loadingState) // sometimes this is a very big conversion function
        // Additional conversion logic
    }
}

With the latest enhancements in Observability, I'm curious about the recommended approach for converting complex application states into SwiftUI-friendly view states. In our app, we extensively use WithViewStore for this purpose, leveraging either computed properties or embedding ViewState directly within the State. However, these strategies seem to complicate binding support and introduce boilerplate due to 1:1 conversions not for the sections but for other properties.

For context, we manage states with multiple nested sections and items, similar to an e-commerce product detail page, where the state includes loading indicators, ad information, and various section-specific data.

In some of the latest videos I've seen examples, where did you do those kind of conversion inside the views themselves which are no go for our concrete scenario, due to it complexity.

Thank you for your insights and suggestions.

[mbrandonw]

Hi @atimca, I believe the suggestions brought up in this thread are the solution to view state.

In particular, it is still completely fine for you to use ViewState even with the new observation tools:

struct FeatureView: View {
  let store: StoreOf<Feature>

  var body: some View {
    let viewState = ComplexViewState(store.state)
    // Use viewState everywhere in here
  }
}

Does this not work for you?

[atimca]

Hi, thank you for the reply! We've implemented the suggested approach in our current setup. While it's functional, it mirrors the complexities we encountered before introducing SharedState. This method demands significant maintenance, especially as our project scales. For instance, we've accumulated 500+ lines of code in State-ViewState converters across some screens, alongside exhaustive 1-to-1 boilerplate for binding states. We're open to continuing with this approach in the absence of a more streamlined alternative.

One limitation we've observed pertains to snapshot or preview scenarios, where converting complex business domain entities into view-friendly formats isn't straightforward. To mitigate this, we aim to decouple our domain entities to ensure views are only aware of relevant ViewState objects. This approach aids in managing complexity but introduces its own set of challenges.

There's an example of complex entity from our project:

struct BackendEntity {
    public var core: AdCore
    public var flags: AdFlags
    public var bids: [BidOffer]?
    public var currentMinimumBid: Int?
    public var sellerInfo: SellerInformation?
    public var metaData: AdMetaData
    public var analytics: Analytics?
    public var flaggingReasons: [Int]?
    public var features: AdFeatures?
    public var sellerMatchingItems: SellerMatchingItems?
    public var casTrackingData: String?
    public var legalDisclaimer: LegalDisclaimer?
    public var locationDescription: String?
    public var pageLocation: String?
    public var paidExtensionInFreeCategory: PaidExtensionInFreeCategory?
    public var reviewSummary: ReviewSummary?
    public var complete: Bool
    public var distanceInMeter: Int?
    public var runningSubscriptionInfo: RunningSubscriptionInfo?
    public var shippingLabel: ShippingLabel?
    public var buyerProtection: BuyerProtection?
    ...
    public var shippingConfig: ShippingConfiguration?
}

Contrastingly, our ViewState is far simpler and designed for the view's consumption:

struct ViewState {
    let sections: [Section]
    let isLoading: Bool
    ...
}

This disparity underscores the necessity for a ViewState driven approach. Perhaps, employing a proxy view that intermediates between State and ViewState could offer a workaround:

struct FeatureWrapperView: View {
  let store: StoreOf<Feature>

  var body: some View {
    FeatureView(store: store.scope(state: ComplexViewState(store.state)))
  }
}

We believe there's room for innovation in this area and hope to contribute our own ideas to the TCA framework in the future. Your insights or suggestions on how to better manage this aspect of state management would be greatly appreciated. 😀

[mbrandonw]

We've implemented the suggested approach in our current setup. While it's functional, it mirrors the complexities we encountered before introducing SharedState.

Hi @atimca, I'm sorry but I'm not sure I really understand what you are describing above.

Are you saying that the ViewState approach I described above does not work for your application? But the ViewStore+ViewState approach does? I would find that surprising because they are basically the same. Can you describe exactly why one approach succeeds where the other approach fails?

Also, are you saying that the "shared state" beta tools we have introduced have made the situation better? Or does "SharedState" refer to something else?

This disparity underscores the necessity for a ViewState driven approach. Perhaps, employing a proxy view that intermediates between State and ViewState could offer a workaround:

We personally do not think these kinds of wrapper views are ever worth it. This isn't accomplishing anything, as far as I can tell, that isn't done with simply doing let viewState = … right in the body of FeatureView.

We are always happy to explore ways of making things better, but I can't say that I understand the actual problem that is being experienced right now.

[atimca]

Hi @mbrandonw, ✌️

I've attempted to clarify our issues in a general manner, but it seems essential details were lost along the way. Regarding the proposed solution, it works for us but comes with some limitations. In reference to SharedState, it's not directly related to my question. I mentioned it primarily as an example. Previously, there were several methods to manage SharedState effectively, and they functioned well. The introduction of SharedState enhanced this process significantly, making our work much easier. I feel we're in a similar situation now: everything functions, but there might be areas for improvement.

Regarding follow-up, I will try to provide clearer code examples and revisit this discussion. Nevertheless, I'm truly grateful for the prompt responses and suggestions. 🙏

[Alex1478]

Hey! TCA is amazing. Also, super stoked by the new 'SharedState'.

I'm a fan of separation of concerns between UI and business logic. Ultimately, I would like to prevent the UI from having access to some child action reducers or state variables that aren't strictly related to presenting the view.

Any way we can replicate the concept of 'ViewAction' that we initially had with 'WithViewStore'? This was a concept that I really liked.

Thanks!
Alex

[mbrandonw]

Hi @Alex1478, this is already possible with the @ViewAction macro. You can also find information about it in the 1.7 migration guide.

[Alex1478]

Oh, thank you for the answer and pointing me to the document. This is great. I definitely need to re-educate myself with the updated documentation. Thanks again! Sent via Superhuman ***@***.***>

…

On Wed, Mar 20, 2024 at 1:08 PM, Brandon Williams ***@***.***> wrote: Hi @Alex1478 <https://github.com/Alex1478>, this is already possible with the @ViewAction <https://pointfreeco.github.io/swift-composable-architecture/main/documentation/composablearchitecture/viewaction(for:)> macro. You can also find information about it in the 1.7 migration guide <https://pointfreeco.github.io/swift-composable-architecture/main/documentation/composablearchitecture/migratingto1.7#View-actions> . — Reply to this email directly, view it on GitHub <#2722 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACB6EOPOHXJ563YAWTSSXN3YZHUEVAVCNFSM6AAAAABCIASQYGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DQNJXGY3DE> . You are receiving this because you were mentioned.Message ID: <pointfreeco/swift-composable-architecture/repo-discussions/2722/comments/8857662 @github.com>