@State variables get reset after pop

[rjo]

Using a standard NavigationView and NavigationLink, the @State variables retain their values when pushed and subsequently popped back into view. iOS example:

import SwiftUI


struct ContentView: View {
    var body: some View {
        NavigationView {
            AAA()
        }
    }
}

struct AAA: View {
    @State var text = "default text"
    var body: some View {
        VStack {
            TextEditor(text: $text)
            NavigationLink(destination: BBB()) {
                Text("Push")
            }
        }
    }
}

struct BBB: View {
    var body: some View {
        Text("BBB")
    }
}

Edit the text, click Push, then go Back. The texteditor retains the changes that were made before pushing.

I tried the same thing with StackNavigationView and find that my @State variable is reset after a pop.

iOS example:

import SwiftUI
import NavigationStack

struct ContentView: View {
    var body: some View {
        NavigationStackView {
            AAA().padding()
        }
    }
}

struct AAA : View {
    @State private var data = "default text"

    var body: some View {
        VStack {
            TextEditor(text: $data)
            PushView(destination: BBB()) {
                Text("Push")
            }
        }
    }
}

struct BBB : View {
    var body: some View {
        PopView {
            Text("Pop")
        }
    }
}

If you edit text the editor, hit Push, then Pop back you see the text has been reset to its default state.

Is this expected behavior?

[ben73]

I'm facing the similar problem. In my case, ScrollView's scroll state is reset.
Is there a solution?

[matteopuc]

Hi @rjo and @ben73, thanks for your question. In SwiftUI when you remove a view from its hierarchy the state is reset. This behaviour is outlined in the README of this project in the Issue section. In that section you can also find a workaround for the problem.

[rjo]

Thanks for pointing our that bit of readme @matteopuc, I had missed that.

However, I'm just really confused as to why NavigationView does not suffer this problem and @State is preserved between presentations. Do we conjecture that NavigationView has some kind of privileged insight into things that allows this behavior?

I've wondered whether NavigationView does not actually remove views from the hierarchy, like it translates them off screen or overlays child views in some way.

Any thoughts?