What to do if SwiftUI views update during the middle of a reducer

[notcome]

I have a complex feature coordinating transitions among two pages. Attached at the end is a mutating method defined on State. Here is the setup:

• I have an IdentifiedArray of PageFeature.State, namely the member .pages.
• I initialized each page's transition values (a custom type) to the default empty value.
• I run a custom transition provider to update these values, and then merge updated values back to each element of the pages array.
• In my view layer, I have multiple pages observing their StoreOf<PageFeature>.

Now, I understand the code below is not optimal. For instance, I can skip initializing them to a default value then merging them -- all I need to do is to assign the final value. But, this not-optimal code seems to reveal a nasty issue:

If we update multiple children states in a reducer, SwiftUI might update views during the middle of the reducer.

In my case, when I initialize the transition values of my tab bar, SwiftUI has 50% chance to decide to update the other two pages, the corresponding states of which have already been touched. There is an unfortunately problem though:

A child store's state is not up-to-date until the root store has finished an action.

I am not sure if this is a bug or intended -- I guess it is the later. But this seems to give us a problem on semantics: we are notifying the systems that some members of our child stores have been changed, but the values are not there. If we have a guarantee that SwiftUI will not process these changes immediately, but to the end of the current loop, we will be fine. However, that does not seem to be the case, and SwiftUI's behavior isn't really deterministic here, according to my observation.

I could improve the code as I mentioned above, reducing writes to child stores. But I am not confident that this will solve the issue in all situations. I do find a workaround though, that is wrapping this store action inside a SwiftUI transaction -- it seems that SwiftUI transaction not only carries animation information, but is also a, as its name suggests, transaction.

Questions:

• Is my understanding correct, that during an action, if we update child ObservableStates, the observation registrar will receive changes immediately?
• And is is true that the new state will not be reflected until the action has been processed?
• If anyone has encountered a similar issue in the past, do you have any idea when it becomes necessary to wrap an action inside a transaction?
• Has anyone encountered a case where even a transaction might not save us here?

mutating func executeTransition(stage: AutomaticTransitionStage) {
    assert(stage == transitionStage)

    let sourceID = transition!.sourcePage
    let targetID = transition!.targetPage

    if pages[id: sourceID]!.pageTransitionValues == nil {
        print("set source ptv to empty")
        pages[id: sourceID]!.pageTransitionValues = .init()
    }
    print("set source ptv.stage")
    pages[id: sourceID]!.pageTransitionValues!.automaticTransitionStage = stage
    if pages[id: targetID]!.pageTransitionValues == nil {
        print("set target ptv to empty")
        pages[id: targetID]!.pageTransitionValues = .init()
    }
    print("set target ptv.stage")
    pages[id: targetID]!.pageTransitionValues!.automaticTransitionStage = stage

    let start = if transition!.isReversed {
        stage == .end
    } else {
        stage == .start
    }

    var context = FullScreenTransitionContext(
        sourcePageLayout: pages[id: sourceID]!.pageLayout!,
        targetPageLayout: pages[id: targetID]!.pageLayout!,
        sourceTransitionValues: pages[id: sourceID]!.pageTransitionValues!,
        targetTransitionValues: pages[id: targetID]!.pageTransitionValues!,
        sourceMorphables: pages[id: sourceID]!.morphableTransitionValues,
        targetMorphables: pages[id: targetID]!.morphableTransitionValues,
        transientViews: transientViews,
        start: start
    )

    transition!.detail.update(context: &context)

    print("merge source ptv")
    pages[id: sourceID]!.pageTransitionValues!.merge(context.sourceTransitionValues)
    print("merge target ptv")
    pages[id: targetID]!.pageTransitionValues!.merge(context.targetTransitionValues)

    pages[id: sourceID]!.morphableTransitionValues.merge(context.sourceMorphables)
    pages[id: targetID]!.morphableTransitionValues.merge(context.targetMorphables)

    for i in transientViews.indices {
        assert(transientViews[i].id == context.transientViews[i].id)
        transientViews[i].transitionValues.merge(context.transientViews[i].transitionValues)
    }

    guard current.showsHorizontalTabBar != target!.showsHorizontalTabBar else { return }
    let tabBarID = AnyPageID(AppTabBarPageID.horizontal)
    if pages[id: tabBarID]!.pageTransitionValues == nil {
        print("set tabbar ptv to empty")
        pages[id: tabBarID]!.pageTransitionValues = .init()
    }
    print("set tabbar ptv stage")
    pages[id: tabBarID]!.pageTransitionValues!.automaticTransitionStage = stage
    let tabBarHeight = pages[id: tabBarID]!.pageLayout!.pageFrame.height

    let toHide = current.showsHorizontalTabBar
    pages[id: tabBarID]!.pageTransitionValues!.offsetY = if toHide {
        stage == .start ? 0 : tabBarHeight
    } else {
        stage == .start ? tabBarHeight : 0
    }
    print("updated tabbar ptv")
}

[mbrandonw]

Hi @notcome,

If we update multiple children states in a reducer, SwiftUI might update views during the middle of the reducer.

This is not true. SwiftUI views are @MainActor bound, as are reducers, and hence it is not possible for them to interleave. A reducer will finish processing all of its logic, and then some moment later the view body will be recomputed.

• Is my understanding correct, that during an action, if we update child ObservableStates, the observation registrar will receive changes immediately?

Well, it is correct that mutations to state notify the registrar, but this happens in the willSet. The registrar (and SwiftUI) can coalesce multiple willSet's into a single re-render of the view.

• And is is true that the new state will not be reflected until the action has been processed?

Yes, because reducers are main actor bound, they must completely finish before the UI has a change to render.

• If anyone has encountered a similar issue in the past, do you have any idea when it becomes necessary to wrap an action inside a transaction?
• Has anyone encountered a case where even a transaction might not save us here?

Can you first describe exactly what problem you are witnessing? It is not clear right now. Also it would help a great deal if you could share a minimal project that demonstrates the problem you are seeing.

[notcome]

This is not true. SwiftUI views are @MainActor bound, as are reducers, and hence it is not possible for them to interleave. A reducer will finish processing all of its logic, and then some moment later the view body will be recomputed.

Okay, it is great, that means my old intuition was aligned with yours, that a reducer must finish before SwiftUI updates its views.

However, on yesterday, with a twisted enough feature (the code I attached was literally copied from my project), I have seen with my own eyes, that SwiftUI did update while a reducer is underway. And I can assure you that both are running on the main thread: not only have I checked it via Thread.isMainThread, I have also seen it from a stack trace:

I didn't bring a reproducible project because I thought you were aware that UI updates and reducer updates might coalesce, and we need to merely discuss some workaround. I will try to reproduce this in a clear, isolated fashion now.

I have reproduced this on iOS 18.1/18.3 on real device, and 18.2 in a simulator. Xcode 16.2 (16C5032a).

[mbrandonw]

You will need to provide a minimal project that reproduces the problem. It's hard to determine anything from this screenshot.

[notcome]

Yes, I fully understand. I just failed to recreate a simple example from scratch. I need to tear down my code piece by piece, which will definitely take a while, if I could ever succeed. I will let you know once I create such an example.