Communicating/reacting to a specific state change between views for two separate yet semi-associated view models - swift

Question

I have a view that consists of two subviews with 1) separate internal states but 2) a high-level state that’s noteworthy to any associated views i.e. each other. That is, a change in one’s high-level state should trigger the other to reconsider/change its own. Imagine – in the interest of keeping it simple/generalisable - a header that has a set of buttons that change based on the option selected in the footer. On the flip side, there’s a button in the header that exits the active state and reset it back to its original state (and therefore the footer’s too).
I’ve managed to conveniently achieve this by adopting a shared universal instance for each view’s view model. The header for example was observing changes in the footer’s view model, and therefore is able react to a change in the footer’s high-level state. However, considering the footer had other internal states (i.e. irrelevant to the header but necessary for the footer view that was observing changes to its own view model), the header view was being re-rendered every time there was any change, regardless of relevance, to the footer view. In reality, at least to my eyes, I wouldn’t notice any visual hiccups but I’m aware this is a fundamentally inefficient (and wrong) way to manage the flow of states. And that if this misbehavior was widespread, then performance is likely to become compromised (visible).
What I have is something along the lines of:
struct HeaderView: View {
// MARK: Observers
#ObservedObject var viewModel: HeaderViewModel = HeaderViewModel.shared
#ObservedObject var footerViewModel: FooterViewModel = FooterViewModel.shared
// MARK: -
var body: some View {
VStack {
switch footerViewModel.state {
case 1: HeaderState1View()
case 2: HeaderState2View()
case 3: HeaderState3View()
}
Button("EXIT", action: {viewModel.reset()})
}
}
}
struct FooterView: View {
// MARK: Observers
#ObservedObject var viewModel: FooterViewModel = FooterViewModel.shared
// MARK: -
var body: some View {
Button("State 1", action: {viewModel.state(to: 1)})
.background(viewModel.state == 1 ? Color.red : Color.clear)
Button("State 2", action: {viewModel.reset()})
.background(viewModel.state == 2 ? Color.red : Color.clear)
Button("State 3", action: {viewModel.reset()})
.background(viewModel.state == 3 ? Color.red : Color.clear)
}
}
class HeaderViewModel: ObservableObject {
// ...
func reset() {
FooterViewModel.shared.reset()
// and other internal state changes
}
// ...
}
class FooterViewModel: ObservableObject {
#Published var state: Int = 1
// ...
func state(to state: Int) {
self.state = state
}
func reset() {
self.state = 1
}
// ...
}
The view models for each is created inside a root-level ViewModel responsible for creating both (and others).
class ViewModel {
var footer = FooterViewModel()
var header = HeaderViewModel()
// etc.
}
That’s created in #main root struct:
#main
struct myApp: App {
// MARK: Variables
var viewModel = ViewModel()
// MARK: Layout
var body: some Scene {
return WindowGroup {
ContentView()
.environmentObject(viewModel)
}
}
}
struct ContentView: View {
// MARK: -
var body: some View {
VStack {
header
/// other views
footer
}
}
Without depending on shared instances of both header and footers’ view models, as I have above, what would the most appropriate/efficient way to achieve what I’m after?
To be more specific/clear, if, for example, the Header and Footer views create a #StateObject of their respective view models i.e.
#StateObject var viewModel: FooterViewModel = FooterViewModel() /// in FooterView.swift
#StateObject var viewModel: HeaderViewModel = HeaderViewModel() /// in HeaderView.swift
How would I be able let any change in HeaderView communicate back to the instance of FooterViewModel that FooterView created?
EDIT:
I imagine one way to possibly achieve this is if I create a third view model that consists of the published shared state and that it’s passed into both views when they’re initialised. But imagine there was more than one published property that needed to be shared between the views, and that there was another view in the mix that needed access to only one of them – would I create two shared view models then: one with publishers for shared properties between all 3 and another with ones for the 2? Doesn’t seem a practical strategy.