Is it a bad practice to make the feature (which implements the ReducerProtocol) a class?

[MojtabaHs]

I have a Feature (I'm calling it a feature because of some additional requirements over the plain ReducerProtocol):

public class IdentificationFeature: TCAFeature {
    public required init() { }

    // MARK: - Dependency
    @LazyInjected(DependencyContainer.serviceManager) var serviceManager
}

So as you can see, I'm using another dependency injection library that lets me inject my dependencies lazily, but lazily mutating a property requires some more extra directives on the struct and its functions.

So one option is to change the struct to a class. A side effect example of this change is when I need to perform a TaskResult, it forces to capture the self:

        case .onIdentifyButtonTap:
            return .task { [self, state] in
                .delegate(
                    .identificationResponse(
                        await TaskResult {
                            let request = RequestDTO(phoneNumber: state.phoneNumber)
                            return try await serviceManager.identify(request) // <- 👈
                        }
                    )
                )
            }
            .cancellable(id: CancelationToken.identificationRequest)

Is it ok to pass the feature around as a reference? What happens if I capture the feature? What happens to the cancelation?

Thanks.

[stephencelis]

I'm not familiar with the library that offers @LazyInjected(DependencyContainer.serviceManager). Can you share what it is and why you're using it over the solution that ships with the library, @Dependency?

We would not recommend using anything but a value type for reducers, for a similar reason that you wouldn't conform a class to be a SwiftUI view: reducers are very lightweight descriptions of behavior, and we expect them to be initialized basically every single time an action comes into the system. Because of this, mutating a class will not behave as you might expect: the class would immediately be reinitialized after it processed the action, and the write would not be visible.

Now this may not matter for your dependency injection library if it writes to some global store, like ours does, but if that is the case, then it's possible that you should be able to use such a property wrapper with a struct anyway, but the setter needs to be marked as nonmutating, probably at the library level.

[MojtabaHs]

The library is 450 lines of code called Factory (formerly Resolver but safer), and it comes with tons of features like.

• Lazy and WeakLazy injections
• Global container override
• Less boilerplate code to achieve the injection needs
• etc

Although the reducers are very lightweight descriptions of behavior, the injected property initialization may be a heavy one. So maybe we need to cache it to some scope (depending on the need) and pass it around instead of reinitializing them.

Also, marking it nonmutating is not a proper solution due to the nature of Lazy initialization.

[stephencelis]

The core implementation of our dependency system is fairly lightweight, as well. Is there something about it that is too heavyweight?

It is also lazy by default, so long as your dependency is vended from liveValue in a lazy way (e.g., a computed property), you get that behavior for free:

extension ServiceManager: DependencyKey {
  var liveValue: Self {
    // Construct and return service manager lazily
  }
}
extension DependencyValues {
  var serviceManager {
    get { Self[ServiceManager.self] }
    set { Self[ServiceManager.self] = newValue }
  }
}

While Factory may provide some interesting features and trade-offs in a lightweight package, one thing to consider is that the built-in dependency system was designed for and is integrated directly into TCA, so you get reducer features for overriding dependencies, as well as guarantees that dependencies are captured correctly through the reducer-effect lifecycle. I'm not sure that Factory can maintain those same guarantees, but if you do use it successfully and have anything interesting to share, let us know how it works out for you!

[alinless]

@stephencelis, with Factory I am able to use network services inside static client behavior, but I can't use it with the Dependency di
Maybe I have missed something. Could you please give me a hint, how to use TCA di with the static context of a feature client?

[stephencelis]

@alinless We have examples of API client usage in the demo apps included with the repo. The case studies app uses a "fact client" throughout, and the search app hits a couple API clients to display weather results. Do those help? If you're having trouble, wanna start a new discussion with more details, including some code that you've tried to get to work and the issues you've had with it?