Pass state to SwitchStore.init view builder

[stephencelis]

Rather than rely on many, many overloads of SwitchStore.init to strictly accept only CaseLets and an optional, final Default view, let's introduce a single initializer without constraints that is passed the current state whenever the case changes. This state can be switched on and route to the appropriate view via CaseLet.

The pros:

• We get exhaustive switching at compile time.

• We get more flexibility in the view layer. Previously, any customization needed to be pushed into the CaseLet builder, but now CaseLet can freely apply view modifiers.

• We can deprecate and eventually remove the many, many initializer overloads, and hopefully slim down binary size in the process, and improve view builder compile times when dealing with SwitchStore. We can also deprecate and eventually remove Default.

• The current overloads only support up to 10 cases, but now we'd support any number.

The cons:

• It's slightly more verbose and repetitive. You have a SwitchStore and then a switch inside it with many cases with CaseLets inside them, and the case .screen: is followed by CaseLet(/State.screen, ...).

• One is free to extract the state's associated value(s) and use it to render a view, but this view will be inert and will not re-render if the value it depends on changes in the store. This can lead to some surprises, but we can document against the pattern, and maybe in the future we can use something like macros to prevent this from being possible.

  SwitchStore(store) {
    switch $0 {
    case let .loggedIn(loggedInState):
      Text("Welcome, \(loggedInState.user.name)!")
      // 👆 This will not re-render if the user's name changes.
    // ...
    }
  }

• You can still get things wrong if you're not careful: there's nothing enforcing that the case you switch on is the same case you send to CaseLet, so case .screenA: CaseLet(/State.screenB, ...) is possible. While unlikely, it's still a copy-paste error in waiting.

  Edit: While this is possible, we've added a runtime warning that will emit when it happens.

[rcarver]

Looking at this diff I'm wondering what function the SwitchStore provides

• Instead of SwitchStore+CaseLet could an IfLetStore perform the same work?
• If you want completeness over all cases, use a ViewStore scoped to state?

Then, thinking about this in terms of navigation, we're often peeling off a single enum case in different parts of the view, not necessarily constructing a complete switch statement in one place. Should we think about other conditional views the same way? Again, maybe IfLetStore is the only tool needed?

[stephencelis]

If you want completeness over all cases, use a ViewStore scoped to state?

If done naively, such a view store would observe all mutations to child state in each associated value, which could easily lead to performance problems and other glitches. SwitchStore automatically de-dupes to only re-render when the case changes using the Swift runtime metadata.

[denysdanyliukboosters]

Hi! I wanted to ask if these changes will remove the limit on the number of CaseLet inside SwitchStore?

[mbrandonw]

Hi! I wanted to ask if these changes will remove the limit on the number of CaseLet inside SwitchStore?

Yes, that should be the case. The only limit will be how many cases are allowed in a @ViewBuilder context, and I believe that is unlimited since it can just nest as many _ConditionalContents as it needs.

[oliverfoggin]

Just to check my understanding... is the intended use case like...

SwitchStore {
  switch $0 {
  case .someCase:
    CaseLet { store in
      SomeView(store)
    }
  }
}

?

Not sure if I understood the full code change reqs from this change.

Thanks

(Also forgive poor code, on my phone with only my left hand at the moment 😬)

[mbrandonw]

Hi @oliverfoggin, that is correct. You will be passed state in SwitchStore so that you can switch on it, and then in each case of that switch you will construct a CaseLet. The diff looks like this:

 SwitchStore {
+  switch $0 {
+  case .someCase:
     CaseLet { store in
       SomeView(store)
     }
   }
 }

[tgrapperon]

This is an idea I already pitched in the past, so I'm all-in with the change! The unobserved state is unfortunate, but it seems indeed that macros will allow to automatically derive an enum like:

enum DestinationStore {
  case a(StoreOf<A>)
  case b(StoreOf<B>)
}

which will allow to replace CaseLet. It is also possible that even SwitchStore will be able to be replaced!. In any case, this PR goes in the right direction. The current locking of overloads to CaseLet members is indeed inconvenient when you want to append additional modifiers, because you can only do this on their content rather than on CaseLet themselves.

[jefflewis]

I used a switch store that I had to break apart into 3 different switch stores due to having too many cases. So if this removes that limitation (as previously commented), I'm more than happy to have a few more case lines while also getting compile time checks on the used cases. 🙌

[kugel3]

I think it would be useful if the original post actually showed concrete examples of the change.

And what does the bullet point below mean? That the "top elements" of the SwitchStore no longer have to be of CaseLet type, so now you can put modifiers on them, not just inside?

We get more flexibility in the view layer. Previously, any customization needed to be pushed into the CaseLet builder, but now CaseLet can freely apply view modifiers.

Also, I wonder if it wouldn't be possible to somehow do the switching as a scoping operation? I mean when we scope, we expose the entire state, transform it and pass it into a child, without even dealing with the question of unwanted redrawing. With SwitchStore we can't do that, because it's a view.

[rhysm94]

Being able to support more than 10 cases would be a phenomenal change!
I use TCACoordinators in a project which uses SwitchStore inside the main router view, and one of the coordinated flows has considerably more than 10 views (and can’t easily be simplified 😬), so I have to hack around it using Group, with loads of Default views.
Being able to remove that, and being able to switch at compile time, would dramatically simplify this code!

[stephencelis]

I think it would be useful if the original post actually showed concrete examples of the change.

@kugel3 The original post shows an example in a counter example, and @mbrandonw posted a small diff example a little before your reply here, but the basic change is that state is passed along and switched on before handing off to CaseLet, rather than a flat list of CaseLets terminated by an optional Default:

 SwitchStore(self.store.scope(state: \.child, action: Parent.Action.child) {
+  switch $0 {
+  case .foo:
     CaseLet(/Child.State.foo, action: Child.Action.foo) { store in
       FooView(store: store)
     }
+  case .bar:
     CaseLet(/Child.State.bar, action: Child.Action.bar) { store in
       BarView(store: store)
     }
-  Default {
+  default:
     Text("DefaultView") 
   }
 }

This provides all the pros listed in the original post, along with some gotchas listed under cons.

And what does the bullet point below mean? That the "top elements" of the SwitchStore no longer have to be of CaseLet type, so now you can put modifiers on them, not just inside?

Yes exactly, as well as Group them, introduce other views, etc.

On main, SwitchStore disallows arbitrary views. It can only be unmodified CaseLet views, one after the other, and an optional final Default view. This PR would remove that restriction and you can basically render what you want (though if you introduce if or switch conditions that render a CaseLet in the wrong place (e.g. you switch and handle case .foo but return a CaseLet(/.bar) from that branch), you'll get a runtime warning.

Also, I wonder if it wouldn't be possible to somehow do the switching as a scoping operation? I mean when we scope, we expose the entire state, transform it and pass it into a child, without even dealing with the question of unwanted redrawing. With SwitchStore we can't do that, because it's a view.

I'm not quite sure what you're suggesting here. Can you sketch out some sample code?

[stephencelis]

Reception seems to be positive, and we think this is the direction, so gonna merge! Feel free to continue the conversation if you have questions, comments, or concerns, though consider starting a discussion for more visibility.