CaseLetStore (for example)

[lukeredpath]

Just putting an idea out there, I'm not really sure what the best API for this would be.

TCA has good support for handling optional state and translating that to a conditional view with IfLetStore, but it feels like the equivalent story for enumerated state is missing, both in the domain and the view.

Right now, you can represent parts of your state as an enum, e.g. to represent distinct states that would also have distinct views but it's awkward to scope to them because the current scoping API is built around key paths.

You can overcome this with computed properties for each sub state, e.g.

enum FeatureState {
  case stepOne(StepOneState)
  case stepTwo(StepTwoState)

  var stepOneState: StepOneState? {
    // etc...
  }

  var stepTwoState: StepTwoState? {
    // etc...
  }
}

With this boilerplate you can now conditionally show the view for each step by scoping over each sub step state using IfLetStore.

It would be great to able to scope based on case paths and lose the boilerplate and I do know some work on this has been done in a branch and I'm keen to give it a try.

However it would also be nice to see the enum equivalent of IfLetStore somehow. It seems a bit odd to have this enumerated state but then in the view there's no indication that the view for each state is distinct because IfLetStore only conveys optional state, not distinct steps.

Would it be possible to come up with some kind of API that allows you to specify the view for each case with the least amount of boilerplate? What would that view look like?

[andreyz]

AFAIK there's a branch called optional-paths that explores support for enum state. Also Point-Free were mentioning that it's being used in isowords (the game) and possibly will be landing in TCA if no serious negative side-effects will be found.

[lukeredpath]

Yes, that's the branch I was referring to in my OP and I do intend to play with it - it certainly improves things on the domain/store side, but with this new feature in the pipeline it would be nice to have an equivalent story for the view.

[siejkowski]

I really like the idea! I think it's a worthy addition for the already existing wrapper on result builder abilities. We have IfLetStore, we have ForEachStore, CaseStore (working name) is covering another use case (pun intended). I've not been modelling my states as enums with associated values, but I could see multiple places in my app in which that would come handy.

I think it's gonna be impossible to provide an API for such store that supports any number of case paths because of the lack of variadic generics in Swift. Same reason why ViewBuilder has all the overloads for buildBlock. Each case path should have a separate generic type for the inner state.

But maybe it's not really a must? You could provide a view for just a single case path and the user, if they need to cover more paths, will just write them one by one like:

CaseStore(testStore, path: /TestState.first) { (store: Store<String, TestAction>) in
  WithViewStore(store) { (viewStore: ViewStore<String, TestAction>) in
    Text("first: \(viewStore.state)")
  }
}
CaseStore(testStore, path: /TestState.second) { (store: Store<Int, TestAction>) in
  WithViewStore(store) { (viewStore: ViewStore<Int, TestAction>) in
    Text("second: \(viewStore.state)")
  }
}

with the naiive implementation of CaseStore:

public struct CaseStore<State, Action, InnerState, Content>: View where Content: View {
  private let content: (ViewStore<State, Action>) -> Content?
  private let store: Store<State, Action>

  public init(
    _ store: Store<State, Action>,
    path: CasePath<State, InnerState>,
    content: @escaping (Store<InnerState, Action>) -> Content
  ) {
    self.store = store
    self.content = { viewStore in
      ViewBuilder.buildIf(path.extract(from: viewStore.state).map { state in content(store.scope(state: { _ in state })) })
    }
  }

  public var body: some View {
    WithViewStore(self.store,
                  removeDuplicates: { _, _ in false }, // not sure how to handle it here without constraining state to Equatable
                  content: self.content)
  }
}

[lukeredpath]

You could possibly inject the removeDuplicates closure into the view by making it an init parameter, but then providing an initialiser on an extension constrained to equatable content that defaults to == - pretty much how WithViewStore itself works.

I think your idea is a good starting point and a lot of this implementation should come for free when the generalised path handling branch drops into main.

I do think some kind of interface that supports an arbitrary number of cases by using overloads might be worth pursuing though - its a bit annoying that you have to do that and of course it requires you to have an overload for each number of options that you support (and which will imply some kind of limit) but perhaps a reasonable maximum could be found for most cases.

I wasn't able to explore this in my OP as I was on my iPad which is a horrible way to type code, but here's what I was thinking. This is virtually pseudo-code:

enum Features {
  case featureOne(FeatureOneState)
  case featureTwo(FeatureTwoState)
}

struct AppState {
  var features: Features
}

var body: some View {
  SwitchCaseStore(store.scope(\.features)) {
    CaseLet(/Features.featureOne, then: FeatureOneView.init(store:))
    CaseLet(/Features.featureTwo, then: FeatureTwoView.init(store:))
  }
}

[stephencelis]

@lukeredpath That's quite interesting! If a SwitchStore could hide away all the details by providing CaseLet an environment object, could reduce boilerplate nicely! If you come up with an implementation we'd love to see it 😄

[lukeredpath]

Yeah...implementing it. That's the interesting bit. 😂

Seriously I'll try and give it a stab, I need to learn more about @ViewBuilder.

[topkim993]

Is there a way to handle cases when features is an array, as in var features: [Features]

enum Features {
  case featureOne(FeatureOneState)
  case featureTwo(FeatureTwoState)
}

struct AppState {
  var features: [Features]
}

var body: some View {
 // How should this part be handled?
}

[mbrandonw]

Hi @topkim993, this is a very old discussion. It would be best to start a new discussion, and please provide as much detail as possible.

[lukeredpath]

OK, I decided to take up @stephencelis' challenge and try and implement something similar to what I suggested above. This is what I ended up with:

SwitchStore(store) {
  CaseLet(
    state: /AppState.featureOne,
    action: AppAction.featureOne,
    then: FeatureView.init(store:)
  )
  CaseLet(
    state: /AppState.featureTwo,
    action: AppAction.featureTwo,
    then: FeatureView.init(store:)
  )
  CaseLet(
    state: /AppState.featureThree,
    action: AppAction.featureThree,
    then: FeatureView.init(store:)
  )
}

This is all powered by the new OptionalPath abstraction in the TCA optional-paths branch and @ViewBuilder.

The downside to this implementation - due to the lack of variadic generics - is the need to define an overload for each number of cases you want to support. In my example code I've implemented up to three but I guess you could take this up to some reasonable maximum, just as SwiftUI does.

Of course, each feature view needs to get a scoped store but you'll notice there's no reference to those scoped stores in the above example - to make this work I've leveraged SwiftUI's @EnvironmentObject to gain access to the parent store in the CaseLet view so I can derive a store scoped to the child state of that particular case.

Because I needed an observable object that lets me get access to the parent store I have introduced a new class, similar to ViewStore, called CaseStore. This wraps the parent store and is set as an environment object on the SwitchStore content view. Not only does this make it accessible to the CaseLet views, it also means the CaseLet views automatically re-evaluate their body when the parent state changes.

Internally the tuple views returned from the SwitchStore view builder are erased to an AnyView - I'm not sure if there is a better solution to this but it seems to work OK.

The full implementation along with some example usage can be found here:

https://gist.github.com/lukeredpath/fde501070878ab3821d4fa41158df31f

Let me know what you think!

[siejkowski]

That is a fine approach! I really dig where the API is going :)

Regarding:

Internally the tuple views returned from the SwitchStore view builder are erased to an AnyView - I'm not sure if there is a better solution to this but it seems to work OK.

Erasing to AnyView should not be necessary, I think. You can add the Content generic type (constraint to View) to the SwitchStore signature. Since you do have to provide the overload initialisers anyway, you can just constraint these overload to corresponding TupleView, like:

struct SwitchStore<State, Action, Content>: View where Content: View {
  let caseStore: CaseStore<State, Action>
  let content: Content

  private init(
    _ store: Store<State, Action>,
    removeDuplicates isDuplicate: @escaping (State, State) -> Bool,
    @ViewBuilder _ content: () -> Content
  ) {
    self.caseStore = CaseStore(store, removeDuplicates: isDuplicate)
    self.content = content()
  }

  var body: some View {
    content.environmentObject(caseStore)
  }
}

extension SwitchStore where State: Equatable {
  private init(
    _ store: Store<State, Action>,
    @ViewBuilder _ content: () -> Content
  ) {
    self.init(store, removeDuplicates: ==, content)
  }
}

extension SwitchStore {
  public init<
    StateA, ActionA, ContentA,
    StateB, ActionB, ContentB
  >(
    _ store: Store<State, Action>,
    @ViewBuilder content: () -> TupleView<
      (CaseLet<State, Action, StateA, ActionA, ContentA>,
       CaseLet<State, Action, StateB, ActionB, ContentB>)
    >
  ) where Content == TupleView<
    (CaseLet<State, Action, StateA, ActionA, ContentA>,
     CaseLet<State, Action, StateB, ActionB, ContentB>)
  > {
    self.init(store) { content() }
  }

  public init<
    StateA, ActionA, ContentA,
    StateB, ActionB, ContentB,
    StateC, ActionC, ContentC
  >(
    _ store: Store<State, Action>,
    @ViewBuilder content: () -> TupleView<
      (CaseLet<State, Action, StateA, ActionA, ContentA>,
       CaseLet<State, Action, StateB, ActionB, ContentB>,
       CaseLet<State, Action, StateC, ActionC, ContentC>)
    >
  ) where Content == TupleView<
    (CaseLet<State, Action, StateA, ActionA, ContentA>,
     CaseLet<State, Action, StateB, ActionB, ContentB>,
     CaseLet<State, Action, StateC, ActionC, ContentC>)
  > {
    self.init(store) { content() }
  }
}

[lukeredpath]

Thanks, I will give it a try. I think tried just passing the content closure to the private init and that didn't work, I didn't think about trying to wrap it in another closure to erase its type.

[lukeredpath]

@siejkowski thanks for the pointer, it needs just a bit of tweaking, especially for the singular CaseLet case:

lukeredpath@273c57b

[nmccann]

Thank you for taking the time to prepare an example implementation @lukeredpath - I incorporated it into a portion of my application to try it out, and found it to be a nice improvement. I even found it worked well in more complex situations, such as one of my views with a state like the following:

struct State: Equatable {
enum Status: Equatable {
case login(Login.Action)
case authenticated(Authenticated.Action)
}

var status: Status
var globalError: Error?
}

There is probably a better way to handle the above (maybe with higher order reducers), but in any case, I was able to just do SwitchStore(store.scope(state: \.status)). Though I did have trouble setting up reducers for the above state, specifically I wasn't sure how to get a WritableKeyPath when performing the pullback on the reducer. Maybe that isn't possible, or I'd need to do something with CasePath (probably something like this).

As I noted here it's possible to for a parent reducer to get child actions that aren't relevant for the current state (ex. login action when you're in authenticated state). Maybe it'd be helpful to have assertions to alert devs of such situations when in debug mode. But I think that could be a nice to have feature built later on (and it should likely be possible to disable it, as we've seen with the assertion for actions on optional reducers - it can be problematic)

The biggest problem with the addition of a SwitchStore is that I'd be compelled to rethink my states to make better use of mutual exclusivity where it makes sense :) Until now I've either been avoiding it, or using optionals, which have their own set of problems (and don't properly convey intent).

Note: I wasn't able to use your fork directly, as SwitchStore and CaseLet weren't public - nor could I copy/paste the gist into my project as it made use of internal functionality from the ComposableArchitecture. I ended up cloning the repo and adding public modifiers where needed, then used the package locally.

[lukeredpath]

@nmccann if you open a PR to my fork with those public modifiers I'll merge it in, thanks for the feedback!

If you're going all-in on enum state you really do want to use the Path/OptionalPath abstraction otherwise you need to add a ton of boilerplate to get the key paths needed.

[strangelearning]

Full circle ⭕️ https://www.pointfree.co/episodes/ep149-derived-behavior-optionals-and-enums#references