Publisher that lives app lifecycle

[chrismiss1]

I saw another similar question and maybe I'm a little dense right now but I still cannot seem to wrap my head around this problem over the last 4-5 days. At its root, my app has a HomeView which is a TabView with various tabs. Almost all of the views in the various tabs share this one piece of data; an array of a custom type, lets say, [SomeType]. For that reason, I've modeled the App.State to hold onto that piece of data and scope it into the child views where necessary. I have a publisher that publishes any time the backend updates [SomeType]. I am getting publishes as expected. In my reducer I always get the first publish, but never any subsequent publishes. I am architecting something wrong and probably misunderstanding something but how can I catch the subsequent publishes and continuously map the new data? On my HomeView, I have:

let store: StoreOf<MyReducerProtocol>

...

.onAppear {
    viewStore.send(.startSync)
}

And in the reducer protocol:

switch action {
                
        case .startSync:

            return someClient
                .publisher
                .receive(on: RunLoop.main)
                .replaceError(with: [])
                .map { .updateData($0) }
                .eraseToEffect()
...

So the updateData action is called on app launch but never again even though my publisher is publishing repeatedly with updates.

Thanks for any hints in advance. If there is an episode, blog or something where this is answered in detail please point me to it!

[tgrapperon]

Hey @chrismiss1! Try to make your long-living effect cancellable. You can check the "Long-living Effect" case study for more informations.
I would also recommend to receive on DispatchQueue.main instead of Runloop.main (or even better, on @Dependency(\.mainQueue)) if you want a more "predictable" behavior, as Runloop.main may schedule the reception after the UI finishes updating. This is not what's causing the issue here, but this can create unwanted behaviors if you're not aware of it.

[chrismiss1]

@tgrapperon Thank you so much for your reply. Can't believe I didnt see that case study. I made the changes but now I must've uncovered a larger issue.. I'm not even getting the .updateData action now...something funky going on. Will start digging a little more

[chrismiss1]

Guessing my publisher is flawed. Will check there first, though I still needed your answer :)

[tgrapperon]

Don't forget about the ._printChanges() method of ReducerProtocol that will give you a clear view of the actions your reducer processes.
The .run approach is easy to inspect too, but if you want to keep using Combine, you also have a .print() method on Publisher that can give you some insight about what's going on there.

[chrismiss1]

@tgrapperon It was my subscription code.. heh.. I did also forget about printChanges. Thanks for everything. We can close this as duplicate or leave it up so people can see the case studies you linked as well as be reminded to double check their publisher/ subscription code :)

[tgrapperon]

Great, glad you sorted it out. As there is no more issue, it is better to close it, especially since it wasn't related to TCA to begin with.