Transitions on inner Views when replacing an outer View altogether
Asked Answered
D

1

0

Starting from this example: Two views in a VStack, coming and going with a different transition:

struct ContentView: View {
    @State var value = false
    
    var body: some View {
        VStack {
            ZStack {
                value ? Color.red : Color.green
                
                VStack {
                    Text(String(describing: value))
                    Button("Toggle") {
                        value.toggle()
                    }
                }
            }
            .id(value)
            .transition(.move(edge: .leading))
            
            ZStack {
                value ? Color.yellow : Color.orange
                Text(String(value))
            }
            .frame(height: 200)
            .id(value)
            .transition(.move(edge: .bottom))
        }
        .animation(.easeInOut, value: self.value)
    }
}

This works fine. Now, what surprised me is this: When you move out the .id-modifier ("replace the outer view"), the inner views don't do the transitions any more:

struct ContentView: View {
    @State var value = false
    
    var body: some View {
        VStack {
            ZStack {
                value ? Color.red : Color.green
                
                VStack {
                    Text(String(describing: value))
                    Button("Change") {
                        value.toggle()
                    }
                }
            }
            // .id(value)   <-- not here
            .transition(.move(edge: .leading))
            
            ZStack {
                value ? Color.yellow : Color.orange
                Text(String(value))
            }
            .frame(height: 200)
            // .id(value)   <-- not here
            .transition(.move(edge: .bottom))
        }
        .id(value)   // <-- moved here
        .animation(.easeInOut, value: self.value)
    }
}

This seems to be how transitions work in the SwiftUI, it seems the transition must go on the View node that's replaced. If a View with a transition comes and goes because its parent View comes and goes, this doesn't trigger the transition.

To clarify the example, here is the same example without using .id() where a container view wants parts of its content to come and go with a transition:

struct View1: View {
    @Binding var value: Bool
    var body: some View {
        VStack {
            ZStack {
                value ? Color.red : Color.green
                
                VStack {
                    Text(String(describing: value))
                    Button("Change") {
                        value.toggle()
                    }
                }
            }
            .transition(.move(edge: .leading))

            ZStack {
                value ? Color.yellow : Color.orange
                Text(String(value))
            }
            .frame(height: 200)
            .transition(.move(edge: .bottom))
        }
    }
}

struct View2: View {
    @Binding var value: Bool
    var body: some View {
        Button("Change") {
            value.toggle()
        }
    }
}


struct ContentView: View {
    @State var value = false
    
    var body: some View {
        ZStack {
         
            if value {
                View1(value: $value)
            } else {
                View2(value: $value)
            }
            
        }
        .animation(.easeInOut, value: self.value)
    }
}

Question: Is it possible to add transitions to inner views in SwiftUI that are triggered by replacing the outer View? (as in: can the last example have transitions while keeping View1/View2 separate/without being sneaky with the View hierarchy?)

Diba answered 29/8 at 9:45 Comment(1)
Somewhat related question: #67860714Diba
E
1

You wrote:

it seems the transition must go on the View node that's replaced

This is correct.

The behavior in your examples can be explained as follows:

  • In the first version, the .transition modifier was on the container (the ZStack). The transitions were working because the id of the container changed whenever value changed. This made it seem like a different container every time.

  • In the second version, the id remains the same, so even though the contents of the container is changing, the container itself is the same. This is why there is no transition happening for the container.

For your re-factored version using View1 and View2, you can get it to work with these changes:

  • In View1, move the .transition modifier from the container to the actual colors, since these are the views that are actually changing.

  • It seems it doesn't work when switching views using a ternary operator, so use an if-else switch instead.

  • You also need to toggle the flag withAnimation, or add an .animation modifier to a containing view.

struct View1: View {
    @Binding var value: Bool
    var body: some View {
        VStack {
            ZStack {
                if value {
                    Color.red
                        .transition(.move(edge: .leading))
                } else {
                    Color.green
                        .transition(.move(edge: .leading))
                }
                VStack {
                    Text(String(describing: value))
                    Button("Change") {
                        value.toggle()
                    }
                }
            }

            ZStack {
                if value {
                    Color.yellow
                        .transition(.move(edge: .bottom))
                } else {
                    Color.orange
                        .transition(.move(edge: .bottom))
                }
                Text(String(value))
            }
            .frame(height: 200)
        }
        .animation(.easeInOut, value: value) // 👈 ADDED
    }
}
Emersion answered 29/8 at 14:46 Comment(1)
Thanks, this lead to solution that spared me quite a lot of ugly workarounds. So one can nest transitions, but you need a separate .animation() to trigger the inner transition. Good find!Diba

© 2022 - 2024 — McMap. All rights reserved.