Adapting Dependencies: Best Practices

[ghost]

Hey everyone, I'm currently working on a project that utilizes the composable architecture, and I'm seeking guidance on adapting dependencies. Specifically, I'm facing a challenge with a reusable view responsible for displaying paginated list of posts. The difficulty arises because the data for this view originates from two different endpoints, with one of them requiring dynamic parameters, which are inputs needed from the parent reducer.

To ensure the composability of both the view and the reducer, I'm unsure of the best approach for adapting this dependency. I'm considering options like duplicating the view, maximizing the configurability of the view, or adapting the web service.

I would greatly appreciate any advice or insights you can provide on how to handle this situation effectively. Thank you in advance for your assistance!

[mbrandonw]

Hi @abdalalii1, it is hard to give a precise answer without knowing more about your exact situation. Perhaps you can sketch out some code that demonstrates what you currently have and what you are trying to accomplish.

At a very high level, the tool that allows you to transform dependencies for just a single feature of the app is the .dependency operator. You can use it to override a dependency of a single reducer (and all its children reducers):

Feature()
  .dependency(\.apiClient, …)

That's the basic tool, but proper usage of it depends on your exact situation.

[ghost]

Hi @mbrandonw,

Thank you for taking the time to respond to my query. Let me provide a brief overview of my situation:

I am facing a challenge where I need to find the best approach to reuse a view with multiple sources of truth. Each source of truth has different methods with varying inputs. The response from these methods is paged, and the input may depend on the user's choices within the view, such as filter options.

To give you a better understanding, here's an example code snippet:

struct PostsClient {
    var allPosts: @Sendable (Int, QueryParameters?) async throws -> [Post]
    var postsOfHashtag: @Sendable (Int, String) async throws -> [Post]
}

Essentially, my reducer needs to call either the allPosts or postsOfHashtag method based on the context of initialization. However, I'm unsure of the best approach to achieve this.

If you have any suggestions or guidance on how I can approach this challenge more effectively, I would greatly appreciate your input. Thank you for your help! I hope I was able to explain and detail my issue clearly.

[lightandshadow68]

If this is constant across the lifecycle of the feature, you could create an initializer on your reducer state that takes an enum with two cases: allPosts(QueryParameters?) and `postsOfHashtag(String). Then use a switch statement in your reducer to determine which endpoint to call and extract the parameters. If this can change across a features lifetime, then your UI can update the case, which can call the correct endpoint when updated.

enum PostsSource: Equatable {
    case allPosts(QueryParameters?)
    case postsOfHashtag(String)
}

struct State: Equatable {
    var source: PostsSource
    
    init(source: PostsSource) {
        self.source = source
    }
}

[ghost]

That’s true, great idea!