Best way for @Dependency to send action to reducer

[GreatApe]

What is the best way to let a dependency notify the reducer that its contents changed? One setup I'm using now is to have a private PassthroughSubject in my dependency, which is wrapped by a public Effect. When the app is launched it sends a .launched action and under that case in the reducer map that effect to an Action:

private let eventsSubject = PassthroughSubject<Event, Never>()
public let eventsEffect: Effect<Event, Never>

init() {
    self.eventsEffect = Effect(eventsSubject)
}
// ...

// In reducer
    case .launched:
        return myDependency.eventsEffect.map(Action.receivedEvent)
    case .receivedEvent(Event):
        // do something

So now for the questions:

Is this a good idea or is there a better way?
Should I instead use an AsyncSequence, and if so, how?

And especially:

• How do I best use this in a leaf reducer? For example, how to I start the subscription?
• For one thing, what would happen if the .launched case gets called multiple times?
• How do I even end this subscription (if I use onAppear and onDisappear, hoping they will balance)?
• Would it be a problem to subscribe to the same dependency in hundreds of leaf views?

Would it be completely crazy to put some common state that often changes and is used by every single leaf view, in the @Environment?

Just FYI, one of the dependencies I need to subscribe to is CoreData, others are my own audio players and similar.

[tgrapperon]

Since the "concurrency" update, the easiest way to handle this is indeed an AsyncSequence of some sort. The most convenient approach involves 2 actions: one that you can call .observeDependency (or .task) that you use to trigger and handle the subscription's lifecycle, and one that you can call .receivedEvent(Value) that you use to perform the changes when appropriate.
In you reducer, you implement:

case .observeDependency:
  return .run { send in
    for await value in myDependency.asyncValues {
      await send(.receivedEvent(value))
    }
  }
case let .receivedEvent(value):
  // Do whatever you need to do each time the value changes.
  state.count = value.count
  return .none

Now in the view, you exploit the fact that the .task modifier spawn a Task that lives as long as the View:

Text("Hello!")
  .task {
    await viewStore.send(.observeDependency).finish()
  }

So this .task awaits for ViewStore to return, but as you can see from the reducer, this will never happen if the async sequence is non-finite. At the end of the day, the .task will cancel itself when the view will go away, and this cancellation will propagate to .run that will cancel itself and end the subscription. Please note the .finish() method that make ViewStore.send an async function that returns when the Effect spawned by the action finishes.

Subscribing in this way in a hundred of views is very likely a bad idea, as it will generate a considerable traffic of actions for the store. You should probably find a way to pass the udpated value along the states while scoping. It doesn't need to be monolithic, and you can maybe have a few subscriptions that handle a few runs of scoped states if it's more convenient in your case.

We would maybe be able to provide more precise feedback with a more explicit use-case. What are your 100 views? rows in a list?

[tgrapperon]

One issue is that I get weird bugs when I use LazyVStack, so right now it's non-lazy, meaning tens of views are "visible".

Are you using an #if available statement somewhere around your TabView by chance? Or AnyView. This is something we found to break Lazy views when interposed between them and a ScrollView (the one from TabView). It is also possible that TabView doesn't play well with Lazy views. I have very little experience with SwiftUI's built-in TabView.

since someone told me you can only have one "consumer" for a sequence.

Indeed, but you can always make a copy of the sequence before iterating. This is what likely happens if it's a value type you extract from a dependency. This is likely not problem if you don't start to iterate twice in the same context/action reduction.

I still haven't managed to create an AsyncSequence on my dependencies

There are several tools to accomplish that, but if you already have a Publisher, you can call .values which returns an async sequence of it.

It should probably be fine if you have 5 or 6 live subscriptions, but you should indeed solve your lazyness problem to begin with.

[JackYoustra]

A side note if it helps: I've had a tough time with getting List's layout to work reliably in lazy contexts, but I've had much more luck with LazyVStacks coupled with ScrollViews.

[tgrapperon]

@GreatApe I've just checked and in any case, livecycle in a TabView works as expected. Only the presented View is alive. So you can probably work your lazyness issue in isolation on a page view. You will need a ScrollView (and only a ScrollView, not a List) for LazyVStack to work.

@JackYoustra Indeed, Lazy stacks and grids are only working correctly in ScrollView. When you put a LazyVStack into a List, you effectively ask to load the LazyVStack as the first cell. As this LazyVStack doesn't see a ScrollView (or maybe it's the opposite internally), it can't decide when its views are beyond the screen boundaries plus a little more, and it loads all its content eagerly. For a Lazy stack to work correctly, you need a clear line of communication between itself and a parent ScrollView. Wrapping LazyStack in AnyView breaks this connection for example.

[JackYoustra]

Apologies, perhaps I was unclear. I was referring to Lists period - I've had moments where swapping a List with a ScrollView { LazyVStack { ... has lead to SwiftUI frame sizing bugs going away

[tgrapperon]

No problem. I clarified the correct use because I've seen folks build List>LazyVStack in the past.

[GreatApe]

So I don't have either compiler directives, Lists or AnyViews, the issue I have is this: #1410. In the real app it disappeared when I replaced a LazyVStack with a plain VStack. It seems to be related to some Apple bug and very random. The tabview does load all the pages when it's created, but then all but the current one disappear, with no duplication.

As to AsyncSequence, I do have a publisher in one of the dependencies, but I'd rather make it an AsyncSequence directly. For the others, I haven't added any subscription stuff yet. Haven't found any basic examples of adding AsyncSequence, do you know any?

[tgrapperon]

The tabview does load all the pages when it's created, but then all but the current one disappear, with no duplication.

Please note that there is a difference between init and body. TabView indeed loads all its views when it appears, but it only renders the body of the one that is visible, so if you don't perform any meaningful work in your inits, it shouldn't really be a concern. But if you have a ScrollView>LazyVStack>ForEach that loads everything in a PageView, you have indeed a SwiftUI problem.

It is very easy to convert your publisher to an async sequence if you're iOS 15+. While doing so, you can focus on the most complex part which is the reducer, and potentially convert your dependency to a pure AsyncSequence in a second step without having to update the logic of your app.

I think documentation will be greatly expanded with the upcoming release of ReducerProtocol. I don't know if there will be more bits on concurrency stuff. But isowords and TCA samples are already fully updated to async/await. The subscription thing is very similar to SwiftUI's case study with the long-living effect. And you can find more information in this collection too: https://www.pointfree.co/collections/composable-architecture/async-composable-architecture

[GreatApe]

It's an iOS 15 app and I am using async await already, the only thing I can't figure out is how to create an AsyncSequence property on my dependency, instead of the publisher.

And yes, it does render all the views on all the pages, and then promptly hides them. Right now the stack is not lazy:

TabView > ScrollView > VStack > (HeaderView, ForEach > Card)

onAppear gets called on each of the Cards inside the ForEach, on each page.

[tgrapperon]

the only thing I can't figure out is how to create an AsyncSequence property on my dependency, instead of the publisher.

As I mentioned above, you can use https://developer.apple.com/documentation/combine/publisher/values-v7nz to quickly create an async sequence from a publisher and implement your reducer. How you can build an async sequence from the ground up depends on the nature of this publisher.

[GreatApe]

Actually it's more like

GeometryReader {
    TabView {
        HomePageView
        ForEachStore {
            ScrollView {
                VStack {
                    GeometryReader {
                        PageHeaderView
                    }
                    ForEachStore {
                        CardView
                    }
                    Spacer
                }
            }
        }
    }
}

So maybe it's all these geometry readers that confuse SwiftUI.

[tgrapperon]

I don't know if a LazyVStack works with multiple views inside instead of one ForEach. You can probably try to remove the GeometryReaders, the PageHeaderView and Spacer to check if it improves the situation. It should also be able to work correctly outside of a TabView. And could also check if assigning some explicit height to CardView helps, as it plays a role with the number of views ForEach will generate in a LazyVStack.

[GreatApe]

Yeah I'll try that. The cards already have explicit height, at least they have a .frame(height: ...)modifier.

As to the TabView, you don't think it's an issue that I'm using ForEachStore rather than ForEach? Couldn't that confuse SwiftUI? Not that I really see a way around that.

[tgrapperon]

ForEachStore is a very thin wrapper around ForEach, and if there are a few things that could be checked, the real problem is with the ScrollView and its descendants. It should be able to work in isolation, outside of the TabView without loading all its views. Once this part is fixed, you can try to reinsert it in the TabView to check if it still works and only load a few views.

[GreatApe]

Thin or not, I imagine it could lead to problems, for example if SwiftUI picks initialiser based on the generic type, like TCA sometimes does. But I will check the things you mention later today.