Reducers with mutli dependencies

[Colin-Fresco]

Howdy!

We have a large app built using tca. We are refactoring down some common patterns that we have found in some of our reducers. We have noticed that reducers with the same data dependencies were getting the same set actions and state requirements.

We need some sort of middleware to handle the chain of events. I'm not sure a subreducer would work for us here and because of the structure of the app it is not so easy change without stopping development work. I was very inspired by reusableFavourite example but I still need some sort of wrapper around my api clients.

For the sake of this discussion imagine I have an app with users favorites which is stored in one api, and another api for getting the actually song and then another to downloading artist information.

I have been playing with the idea of the liveKey doing a lot of the work, so I’d have Favorite Service liveValue that access Song Service and Artist Service to provide the correct information back to the reducer.

public enum FavoriteKey: DependencyKey {
    public static let liveValue: FavoriteService = live
    struct live() {
        let song = SongService.liveValue
        let artist = ArtistService.liveValue
        FavourtieService(getFavoriteSong: {
            AuthService.liveValue.IfLoggedIn {
                await urlSession.getFavouites() // make a call to get favouites
                await SongService(getSongs: favouites)
                await ArtistService(getArtist: songs)
                return [FavouiteWithSongAndArtist]
            }
        })
    }
}

My current setup:

And looking to do something like this:

So basically I need some sort of middleware/usecase sort of class that can wrap the logic and provide it neatly to the reducer.

Do you have any good example you could provide?

[mbrandonw]

Hi @Colin-Fresco, I can't say I 100% understand the situation you are describing, but if it all boils down to asking if it's ok for a dependency to encapsulate other dependencies with logic, then yes that is typically OK.

However, there are some things to be aware of:

• First, the more logic you move out of your reducer and into your dependency the less the TestStore will be able to help you write exhaustive tests. You will have more responsibility to make sure you are testing the true behavior of your features. You may want to even start writing some test for the dependency itself as an isolated unit, separate from your reducer features. We do this for the AppStorageKey and FileStorageKey that are used with @Shared since they encapsulate quite a bit of nuanced logic.

• You will still want to use @Dependency inside of your dependencies so that you have the option for overriding sub-dependencies, if that is something you do.

• And lastly, you should consider whether all of this logic could be executed in an effect rather than defining a new dependency. For example, if your reducer was doing this to go through multiple layers of effects:

  case .buttonTapped:
    return .run { send in send(.favoritesResponse(favoritesService.fetch()) }
  case let .favoritesResponse(response):
    return .run { send in send(.songsResponse(songsService.fetch(response.favorites))) }
  case let. songsResponse(response):
    return .run { send in send(.artistsResponse(artistService.fetch(response.songs))) }
  case let .artistsResponse(response):
    // Do something with response

  Then you could instead do all of that in a single effect:

  case .buttonTapped:
    return .run { send in 
      let favoritesResponse = await favoritesService.fetch()
      let songsResponse = await songsService.fetch(favoritesResponse.favorites)
      let artistsResponse = await artistService.fetch(songsResponse.songs)
      await send(…)
    }

  And you could even extract that async work out into a helper so that multiple reducers can access that logic.

[Colin-Fresco]

Thanks for taking the time to answer. The point on Teststore is an important one as I straight away faced it when moving my logic out of the reducer.

I think I need a helper and some sort child reducer that all my screens can use. The issue is the app has so many entry points we need to get the data (the favorite songs) in every screen but every screen is currently doing the get action, result action, get the next bit action, result etc.

It's helped to give me few ideas...which will probably turn into more question I'll ask on slack :D