What's a good way to cast results of a subscription in SwiftUI to a desired output type? about reswift

[DivineDominion]

If ActiveBookState doesn't delare a lot of properties that all conforming types have to implement, and for which the protocol creates a useful abstraction, I'd start with an enum instead.

As for the subscription:

@ObservedObject var activeBookState: Subscriber<ActiveBookState> 
    = Subscriber(store)  { $0.select { $0.activeBookState } }

This looks fine if you're interested in the general type (or the enum itself.

For the binding, I'd introduce (derived) view model data:

.disabled(activeBookStateIsActive)

and then

or, cheekily, in a private extension to your UI component for convenience:

extension TheSwiftUIView {
  fileprivate var activeBookStateIsActive: Bool { activeBookstate.value is ActiveBook }
}

---

With an enum, these things would flow a bit more naturally. I'm personally not a fan of boolean type checks. If that's used, it can probably also be modeled as a property of the receiving object instead, too, e.g.:

protocol ActiveBookState {
  var isActive: Bool { get }
}
struct NoActiveBookState : ActiveBookState {
    var isActive: Bool { false }
}
struct ActiveBook: ActiveBookState {
    var isActive: Bool { true }
    // other props
}

The type names and the property in combination sound super weird, though :) I'd try to come up with something else to be honest that expresses the different kinds better

[alexwhb]

@DivineDominion This is fantastic! Thank you so much for your comprehensive writeup. I'm going to try out your suggestions. I was leaning towards using an enum but was not sure if that was standard practice or not. I'm a bit new to Swift and iOS so excuse my ignorance. I typically live in Android land. I also agree with you that my naming is a bit weird... Diffidently a work in progress. :)

[DivineDominion]

@alexwhb Swift enums are pretty powerful but also weird at first. Your sample code's types looked similar to the Result or Optional type to me, so that's why I suggested using an enum. When a type hierarchy makes more sense, by all means use that :)

Am closing the issue for now. Please reopen if things don't work.