Working with non-optional state

[cheif]

Hey!

We're almost extensively using swiftui-navigation for handling navigation in our app, but recently we've come up with a use case where the tooling isn't 100% there yet, so I'd be interested to hear your opinions on:

1. Does you agree that this is a reasonable way to model the domain?
2. Would it make sense to extend the library to support this usecase?

The model

In our app we're using the familiar pattern from Maps, using a Map with an overlayed list, which will switch to a detail view once something is selected. Previously we've used custom UIKit implementations for most things, but with the arrival of presentationDetents we've made the jump to 100% SwiftUI.

Our model looks something like this:

class ViewModel: ObservableObject {
    @Published var state: State
    
    @CasePathable enum State {
        case loading
        case list(ListViewModel)
        case detail(DetailViewModel)
    }
    ...
}

And similarly the view looks something like:

struct MyView: View {
   @ObservedObject var viewModel: ViewModel

   var body: some View {
        Map(
           ...
        )
       .sheet(unwrapping: Binding(get: { (/ViewModel.State.list).extract(from: viewModel.state) }, set: { _ in })) { $ViewModel in
           ListView(viewModel: viewModel)
               .presentationDetents(...)
       }
       .overlay(alignment: .bottom) {
            switch viewModel.state {
                case .loading: 
                     ProgressView()
                case .detail(let viewModel):
                     DetailView(viewModel: viewModel)
                case .list:
                     EmptyView()
       }
   }
}

The thing that sticks out here is the manual creation of a Binding needed for the .sheet, this is due to there's (currently) no support in the library for deriving bindings from non-optional state. (Unless I've completely missed it)

Adding such a conformance is pretty simple:

extension Binding {
    // This allows us to get a Binding for a case from a non-optional Enum, this isn't provided out of the box by `SwiftUINavigation` but maybe it should?
    public subscript<Member>(
      dynamicMember keyPath: KeyPath<Value.AllCasePaths, AnyCasePath<Value, Member>>
    ) -> Binding<Member?>
    where Value: CasePathable {
        Binding<Member?>(get: {
            Value.allCasePaths[keyPath: keyPath].extract(from: wrappedValue)
        }, set: { newValue in
            guard let newValue else {
              return
            }
            wrappedValue = Value.allCasePaths[keyPath: keyPath].embed(newValue)
        })
    }
}

and I imagine it could be written even cleaner if it was part of the library.

Question

So back to my questions, do you think the modeling above makes sense, or would there be a better way to solve it?

If the modeling makes sense, do you think this is something that would fit nicely in the scope of the library?

[mbrandonw]

Hi @cheif, the reason the binding tools are tuned for optional state is because that gives us a natural way to dismiss a feature: you just write nil to the binding.

In your situation you want to present a sheet based off the .list case of model.state, but what happens if the user swipes down on that sheet to dismiss it? Should the state be reset to loading? Currently your binding helper will just do nothing, and so in fact your model will be inconsistent with what is displayed on the screen.

It seems like a better way is to ditch the loading case and use an optional instead:

class ViewModel: ObservableObject {
  @Published var state: State?

  @CasePathable 
  enum State {
    case list(ListViewModel)
    case detail(DetailViewModel)
  }
}

And then the sheet(item:) API will work just fine:

.sheet(item: $model.state.list) { model in
  ListView(model: model)
}

[cheif]

Sorry, I realize I wasn't totally clear in my example.

The intention is that you can't dismiss from the list state, you'd enter the feature in the .loading state (while doing a network call), then transitioning to .list (and maybe to .detail, if the user selects something).

Meaning that after the initial .loading state, you'd always be in either .list or .detail, why modeling it as non-optional makes sense (in my mind at least).

Does that make my example clearer?

[mbrandonw]

In that case I think you are unfortunately fighting against the domain modeling tools of SwiftUI. While SwiftUI does give you a way to present a sheet that is not interactively dismissible by the user, that fact is not represented in the domain at all. At the end of the day the sheet is still driven by a binding of an optional value, and technically someone could try writing nil to it.

And so I think my suggestion above is still the way to go. You drop the .loading case and think of nil as being "loading", and then you can easily derive bindings of the correct shape, and you will use interactiveDismissDisabled() on the sheet to prevent the user from dismissing.

If we were to provide the tool that you sketched out above it would be possible for people to use it with a sheet in which interactiveDismissDisabled() has not been set. That will mean the user can swipe-to-dismiss the sheet and the model's state will not be updated accordingly, leaving the model and view in an inconsistent state. So we rather that not be possible.

[cheif]

Thanks for your explanation, I hadn't really considered the fact that domain-wise .sheet will always be user-dismissible, even if that's not what we're intending at all. I totally understand that my addition wouldn't fit in the library, and I'll keep it as a local extension for now (with the caveats listed here clearly stated).

I also tried your suggestion, ditching the .loading and making the binding optional, that does work out partly, but unfortunately when we're selecting something in the list, AKA transitioning from .list to .detail, SwiftUI will first show the detail screen, but then immediately write nil to the binding, making everything disappear.
I'm pretty sure this is something happening deep within SwiftUI, and not stemming from the library, but it means we'll still need to somehow swallow that nil stemming from the dismissal of the .sheet. That can probably be accomplished by doing some read-only transformation of the binding, .sheet(unwrapping: $viewModel.state.list.readOnly()), but I think I'll just keep my custom tool for now.

Thanks for a great explanation, and for providing such nice tools to work with Swift/UI! 🎉

[mbrandonw]

...SwiftUI will first show the detail screen, but then immediately write nil to the binding, making everything disappear.

This is just a vanilla SwiftUI bug. If you space out the mutation by first writing state = nil, then waiting 0.3 seconds, and then state = .detail, it should work.