1. 9
    1. 1

      I’m still getting the hang of SwiftUI, but I notice you’re using @State (as is the Hacking with Swift example) instead of @StateObject or at least @ObservedObject. I thought not using those macros means you wouldn’t have working observability in the view side?

      1. 2

        @Observable on the model is the newer version of those property wrappers. Combined with @State in the view, all properties of the class get the pub/sub behavior.

        1. 1

          Ah, I was targeting a release before those macros were available.

      2. 1

        Thanks for sharing your post. I was wondering about this line:

        I take it a step further and simply name the class Model:

        Why not stick with the name ViewModel? Or do you end up not following the “Model” part of the MVVM pattern?

        I ask because I’ve found having a separate Model value type is really nice for testing and modelling any Views that are moderate to high complexity. Combining ViewModel + Model into one is all right for a very simple UI (like maybe two user input fields max).

        1. 1

          It’s literal just because I prefer the brevity. Whole a View’s view model “Model” probably deals with something in the model layer proper, I haven’t had any confusion come out of it yet.