How to animate the dismissal of an IfLetStore view

[ylorn]

Take an example of the FactPromptView from Derived Behavior: Optionals and Enums, which is a bottom banner wrapped in an IfLetStore view that can be dismissed by nilling out the corresponding state value in AppState in the appReducer.

My question is: how to animate the dismissal?

I have tried:

1. Specifying the animation when sending the .dismissButtonTapped action in the FactPrompt view:

          Button("Dismiss") {
-             viewStore.send(.dismissButtonTapped)
+             viewStore.send(.dismissButtonTapped, animation: .easeInOut)
          }

2. Adding an animated scheduler to the factPromptReducer for action .dismissButtonTapped:

let factPromptReducer = Reducer<FactPromptState, FactPromptAction, FactPromptEnvironment> { state, action, environment in
  switch action {
  case .dismissButtonTapped:
    return .none
+          .receive(on: environment.mainQueue.animation(.easeInOut))
+          .eraseToEffect()

  case .getAnotherFactButtonTapped:

3. Adding an animated scheduler to the appReducer for action AppAction.factPrompt(.dismissButtonTapped):

    case .factPrompt(.dismissButtonTapped):
      state.factPrompt = nil
      return .none
+            .receive(on: environment.mainQueue.animation(.easeInOut))
+            .eraseToEffect()

4. Wrapping the IfLetStore in a explicit animation block:

+      withAnimation(.easeInOut) {
          IfLetStore(
            self.store.scope(
                state: \.factPrompt,
                action: AppAction.factPrompt
            ),
            then: FactPrompt.init(store:)
          )
+      }

Unfortunately, none of them above works.
Any ideas how to achieve the expected animation? Thanks in advance.

[iampatbrown]

Hmm this is actually something that might be able to be fixed at a library level...
I've worked around it a few different ways before, but the simplest is probably to wrap IfLetStore in a ZStack

ZStack {
  IfLetStore(
    self.store.scope(
      state: \.factPrompt,
      action: AppAction.factPrompt
    ),
    then: FactPrompt.init(store:)
  )
}

then viewStore.send(.dismissButtonTapped, animation: .easeInOut) should work.

Let me know how you go.

[ylorn]

Thanks for looking into this. It comes as a surprise that the view needs to be wrapped inside a ZStack for the animation to work. Would you care to explain why?

Hmm this is actually something that might be able to be fixed at a library level...

+1 for this. Shall I convert this to a bug issue?

[iampatbrown]

It's not exactly a bug, just something that's easy to overlook.

In this case IfLetStore is inside the same ZStack as the List. The ZStack is responsible for transitioning views in and out (ie. animating the dismissal). When the FactPrompt view gets dismissed, it actually disappears behind the List because the .zIndex is now lower than the List. You can confirm this by adding .opacity(0.5) to the bottom of List.

The animation issue can also be fixed by adding .zIndex(1) to the IfLetStore. Also, you can wrap IfContent and ElseContent in their own ZStack if you wanted to control the transitions individually. Here's an example of how that could look:

IfLetStore(
  self.store.scope(
    state: \.factPrompt,
    action: AppAction.factPrompt
  ),
  then: { factPromptStore in
    ZStack {
      FactPrompt(store: factPromptStore)
    }
    .transition(.asymmetric(insertion: .move(edge: .bottom), removal: .opacity))
  },
  else: {
    Color.gray
      .ignoresSafeArea()
      .frame(height: 60)
      .overlay { Text("Numbers are interesting!") }
  }
).zIndex(1)

Thinking about it the current behaviour is probably preferred in case you do need to control the .zIndex in relation to views inside the same container.

Hope that helps clarify things a bit more. Let me know if I can help with anything else.

[ylorn]

In this case IfLetStore is inside the same ZStack as the List. The ZStack is responsible for transitioning views in and out (ie. animating the dismissal). When the FactPrompt view gets dismissed, it actually disappears behind the List because the .zIndex is now lower than the List.

Thank you so much for the walkthrough and the detailed code example. Now I fully understand what is going on! 🙏🏼

[ylorn]

@iampatbrown

After some thinking I still think the extra work for the animation to work (i.e. ZStack wrapping, .zIdenx(:) suffixing) should not be performed by the user of IfLetStore, but done within the ComposableArchitecture library. Because the IfLetStore is almost certainly used for some derived child state that exists in the parent state as an Optional value, which means it gets nil-out at some point when an action received or some state changes, and gets assigned to a concrete value in some other situation. Accordingly, the View associated with the child state is to be displayed or dismissed according to the presence of its value. Therefore it makes no sense for the user to do extra work to make the IfLetStore CAPABLE of perform the animation specified by the user, instead it should be able to handle that out of the box, since it is designed specifically for an use case where appearing & disappearing of the view definitely will happen.

cc @stephencelis

[iampatbrown]

That was my initial thought as well, however, the behaviour isn't limited to TCA.

At the moment IfLetStore behaves the same as ViewBuilder.buildIf() and ViewBuilder.buildEither() which I'm inclined to think is preferable. Here's an example that might not be possible if IfLetStore acted more like it's own container

struct ContentView: View {
  @State var bool = true

  var body: some View {
    ZStack {
      Color.red
        .padding()
        .zIndex(0)

//      ZStack { 
        if self.bool {
          Color.green
            .zIndex(2)
        } else {
          Color.gray
            .zIndex(-1)
        }
//      }
    }
    .safeAreaInset(edge: .bottom) {
      Button("Toggle") {
        withAnimation { self.bool.toggle() }
      }
    }
  }
}

it makes no sense for the user to do extra work to make the IfLetStore CAPABLE of perform the animation specified by the user

Keep in mind, this is more of a ZStack issue. It may in fact be considered a SwiftUI bug. If you change all the .zIndex modifiers to the same 'non-zero' index, eg. .zIndex(1), the animation is as you'd expect... which I think is kind of strange...

My main concern is that changing IfLetStore might make something else impossible to achieve. Not exactly sure though :) Interested to hear other peoples' thoughts on this.

[ylorn]

Pity that SwiftUI is not open-sourced, it is incredibly powerful and convenient, yet its powerfulness and convenience come with a cost that the hidden implementation is out of reach and the behavior is not very well documented.