Did you experience instantiation issue when using @StateObject

[twittemb]

Hi

@mbrandonw I saw you were experimenting with @StateObject in WithViewStore.

I’m my self playing with that (create a StateObject in an init) and I encountered a weird instantiation behaviour where the wrapped value could be created twice. It happens only if the View (WithViewStore in your case) is embedded in a NavigationStack AND there is some state driven component inside the View (WithViewStore in your case).

I ask the question because you might have the issue as well.

Here is what the code would look like (not my exact code per se but a simplified version for the sake of clarity).

struct MyView: View {
  @State var path = NavigationPath()
  @State var text = “”

  let depResolver: () -> MyDependency

  init(depResolver: @escaping () -> MyDependency) { // where `MyDependency` is an ObservableObject
    self.depResolver = depResolver
  }

  var body: some View {
    NavigationStack(path: $path) {
    // `WithDependencyView` is a SwiftUI view that instantiates the dependency by executing `resolver` and publish as a @StateObject (like `WithViewStore`)
      WithDependencyView(resolver: self.depResolver) { dependency in
        Text(“\(dependency.value)”)
        TextField(“Input”, $text, axis: .horizontal) // if that line is commented, the depResolver is called once, twice otherwise
      }
    }
  }
}

struct ContentView: View {
  var body: some View {
    MyView(depResolver: {
      print(“depResolver”) // —>> printed twice if the TextField is no commented
      return MyDependency()
    })
  }
}

[mbrandonw]

Hi @twittemb, I don't know if I've seen this exact issue, but definitely there are lots of view configurations you can do that cause very weird things to happen. For example we have this UI test that shows how SwiftUI can write to a binding long after the view has gone away, and it's only reproducible with a hierarchy of VStack > ForEach > HStack > TextField. And TextFields in particular are thorny in SwiftUI, often writing multiple times to its binding or writing to its binding at weird times.

That's the only concrete thing I can say, but if you can share more code so that I can reproduce this locally I'd be curious to see what is going on.

[twittemb]

Thanks for you answer.

here is a code that will demonstrate that:

import SwiftUI

@main
struct MyApp: App {
  var body: some Scene {
    WindowGroup {
      MainView(resolver: makeDependency)
    }
  }
}

func makeDependency() -> MyDependency {
  print("makeDependency")
  return MyDependency(value: "5")
}

class MyDependency: ObservableObject {
  @Published
  var value: String

  init(value: String) {
    self.value = value
  }
}

struct MainView: View {
  var resolver: () -> MyDependency

  @State var text = ""

  init(resolver: @escaping () -> MyDependency) {
    self.resolver = resolver
  }

  var body: some View {
    NavigationStack { // if commented, no double dep resolution
      WithDependencyView(resolver: resolver) { dependency in
        VStack {
          Text(dependency.value)
          TextField("Input", text: $text, axis: .horizontal) // if commented, no double dep resolution
        }
      }
    }
  }
}

// equivalent to WithViewStore
struct WithDependencyView<Content: View>: View {
  @StateObject var dependency: MyDependency
  let content: (MyDependency) -> Content

  init(
    resolver: @escaping () -> MyDependency,
    @ViewBuilder content: @escaping (MyDependency) -> Content
  ) {
    self._dependency = StateObject(wrappedValue: resolver())
    self.content = content
  }

  var body: some View {
    self.content(self.dependency)
  }
}

[tgrapperon]

Reposting my response from Swift Forums:
From my experience, NavigationStack scouts the view tree ahead and on its own (independently of view invalidation), probably to look for navigationDestination. So this is maybe what you're experiencing.

[tgrapperon]

To expand a little: According to my experiments, SwiftUI lazily resolves types in NavigationPath, as there is not enough information saved on its own (the unmangled name) by the codable representation. See this and this for reference.
So my feeling is that NavigationStack looks ahead for navigationDestination to resolve the kind of values it may have to extract from the codable representation (because once you have the type, you can have its unmangled name and check that it corresponds to what you have, but you can't rebuild the type from the unmangled name alone).
This is can cause a lot of similar issues. I've also experienced this while working on a workaround to deep navigation bugs, while trying to use preferences to bubble bindings up. This made the workaround impossible to implement, as it wasn't possible to disambiguate real preference traffic from "NavigationStack"-related one.
@mbrandonw If this is really what's happening, it's maybe something to assess in the scope-store branch (I don't think it can cause issues as we're not basing anything yet on the assumption that things are only happening once).
Again, these are mostly suppositions, so please take everything with a grain of salt.

[tgrapperon]

A very simple repro:

final class Model: ObservableObject {
  init() {
    print("Init Model")
  }
}

struct ContentView: View {
  var body: some View {
    NavigationStack {
      LinkAndDestination()
    }
  }
}

struct LinkAndDestination: View {
  @StateObject var model: Model
  init() {
    self._model = .init(wrappedValue: Model())
  }
  var body: some View {
    NavigationLink(value: "") {
      Text("Go")
    }
    .navigationDestination(for: String.self) { _ in
      Color.yellow
    }
  }
}

struct Link: View {
  @StateObject var model: Model
  init() {
    self._model = .init(wrappedValue: Model())
  }
  var body: some View {
    NavigationLink(value: "") {
      Text("Go")
    }
  }
}

struct Destination: View {
  @StateObject var model: Model
  init() {
    self._model = .init(wrappedValue: Model())
  }
  var body: some View {
    Color.orange
      .navigationDestination(for: String.self) { _ in
        Color.yellow
      }
  }
}

struct NoLinkAndNoDestination: View {
  @StateObject var model: Model
  init() {
    self._model = .init(wrappedValue: Model())
  }
  var body: some View {
    Color.orange
  }
}

It initializes the model twice when the body contains a NavigationLink or a .navigationDestination, but only once if it doesn't contain any of these.

[tgrapperon]

It also happens with @StateObject that are defined/assigned in the View itself. I've filed FB11959288 to get a track of it.
According to the recent exploration in UITesting, I'm wondering if we shouldn't have a project that tests a few of these issues somewhere to get a better picture of their current state.

[twittemb]

FB11959288

Also open a radar FB11959397

[twittemb]

Thanks a lot for all your nice answers. I assume it is a bug then. I'll try to fill a radar as well.

I can't think of a workaround for now. I can't change my view hierarchy as the path of NavigationStack is bound to my dependency :-(