Example of using classes in destination enum in SwiftUI?

[ZevEisenberg]

What's the recommendation for storing child feature view models inside cases in a navigation destination enum? I’ve pieced together some things, but nothing holistic:

1. I’m not using TCA in this project (or I wouldn't be asking this question!)
2. Child models are @Observable classes on iOS 18+.
3. I’d like to be able to have one switch in my view to exhaustively handle all possible nav destinations of a particular type (sheet, nav push, etc).
4. I don’t (currently) need a Binding to the class values that I unwrap from the enum.
5. It looks like my enum Destination needs to be Identifiable or Hashable, and that gets messy when I start nesting objects inside cases. I have to do a bunch of many overloads of var id or hash(into:).

In the swift-navigation example project, I found WiFiSettingsModel, which shows how to nest observable models inside a destination enum. But it's a UIKit case study, so we can't see the the full picture of how to wire it up end-to-end with classes inside enums in SwiftUI.

[ZevEisenberg]

I can do everything I want if I make the view model Hashable with nonisolated witnesses for == and hash(into:), which is goofy but not completely unreasonable perhaps? I've just found HashableObject in the library. Is that the way to go?

[agarrharr]

I'm not sure exactly what you're trying to do, but I've made several @Perceptible view models conform to HashableObject.

[mbrandonw]

Is that the way to go?

Absolutely. In fact, object identity is the only valid choice for Hashable conformances in reference types (with one small exception that is not worth noting, but let me know if you ant to know). We did an entire series of episodes detailing why if you use the data in your class for Hashable you are in for a world of hurt.

[jonduenas]

It's worth calling out that Apple does have some clear guidance on this.

Avoid using model types as elements of a navigation path. Make sure the elements of navigation paths are lightweight, and don’t use them as a mode of transport for data models.

Source: Understanding the navigation stack

It also impacts things like restoring the stack later using the Codable representation. You'd have to figure out an alternative way to do that if you needed.

[ZevEisenberg]

Good shout. It's super annoying, though, if you want to do precise domain modeling 😭

In my case, I don't need to decode the nav stack, so I may forge ahead with this anyway. I just need to figure out the right incantation to use NavigationLink with this setup.

[mbrandonw]

It's worth calling out that Apple does have some clear guidance on this.

Like with most guidance from Apple in SwiftUI, I would take this with a grain of salt. There is nothing fundamentally wrong with doing this. Even the codability works just fine. You will simply encode the bare essentials of the model (such as the ID of the item you are viewing). All other state gets generated once the view appears and the model is interacted with.