How to decide when to create a new, dedicated dependency for a feature?

[phi161]

Suppose we have a feature showing a list of a user's items.

There's a "repository" that provides all items (not just the user's):

struct ItemRepository {
	public var allItems: @Sendable () async throws -> AsyncStream<[Item]>
	// we can also return a Publisher or an Observable
}

and a UserManager providing the item ids:

struct UserManager {
	public var userItemIds: @Sendable () async throws -> AsyncStream<[String]>
	// we can also return a Publisher or an Observable
}

Please note that both endpoints are modeled as "streams"; the available items might be updated on the server and a user can add/remove items on the web, so we'd like to be notified about these changes.

Is it advisable to create a dedicated ItemFeatureClient that will be the actual @Dependency of our TCA-powered ItemFeature? This client will depend on ItemRepository and UserManager, combine the two streams, filter the results and the reducer will just consume them in.run {}.

But we could also add both ItemRepository and UserManager as feature dependencies and do the filtering in the reducer, right? In that case we can easily mock both of them and even test the business logic of filtering, but how do we know when to stop? In our real-world scenario, ItemFeatureClient depends on a few more components (not just two), and we feel that we'll be abusing the reducer if we move all our business logic there (remember, the user will always see the filtered results, there's no UI interaction).

This question relates to another discussion about dependencies, but we're still not sure how to design our APIs (especially given that both ItemRepository and UserManager will be used in different ways, from other features).

[mbrandonw]

There's another possibility to consider that is related to the second style you described. You can create a computed property on DependencyValues, which has access to the item repository and user manager, in order to do the combining and filtering logic:

extension DependencyValues {
  var userItems: AsyncStream<[Item]> {
    get async throws {
      let items = try await self.itemRepository.allItems() // ✅
      let ids = try await self.userManager.userItemIds() // ✅
      // Do work in here to combine their latest values and output
      // an array of the filtered items.
    }
  }
}

And then in your reducer you can use it quite simply in a .run:

@Dependency(\.userItems) var userItems

…

return .run { send in 
  for await items in self.userItems {
    await send(.itemsResponse(items))
  }
}

Alternatively, and pretty much equivalently, you can create a little helper that can be used from the reducer:

func userItems() async throws -> AsyncStream<[Item]> {
  @Dependency(\.itemRepository) var itemRepository
  @Dependency(\.userManager) var userManager

  let items = try await itemRepository.allItems() // ✅
  let ids = try await userManager.userItemIds() // ✅

  // Do work in here to combine their latest values and output
  // an array of the filtered items.
}

I personally think it will work out best if you keep your dependencies as simple, atomic units, and then perform as much of the business logic in the reducer as possible. But the above shows that you don't have to literally put everything in the reducer. You can still create little shareable units of logic that can be called to from the reducer.

[ahbou]

Slightly unrelated question to dependencies but we're in a similar situation with AsyncStream

@mbrandonw you said:

// Do work in here to combine their latest values and output

How would one combine their latest values and output?
Coming from RxSwift we're used to combineLatest but AsyncAlgorithms only support AsyncSequence.

[mbrandonw]

Hi @ahbou, since AsyncStream is itself an AsyncSequence you should be able to use all of the operators in AsyncAlgorithms just fine.

[ahbou]

I was under the false impression that they wouldn't work.
Thanks @mbrandonw 🙏