Nested DependencyKeys & Delegates - Anti pattern?

[Kondamon]

First of all thank you for this excellent framework!

I couldn't find any information if nested DependencyKeys or delegates within DependencyKeys are an anti pattern to avoid. My use case is to have canAccess dependency key in a swift package framework. When a feature can't be accessed a delegate call is done to inform the app and show a screen.

@Dependency(\.canAccess) var canAccess

/// Check if access is allowed (in framework)
func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
    switch action {
    case .tappedButton:
    /// Checking access and triggering delegate in (nested) DependencyKey
    guard canAccess(.unlimitedEntries) else { return .none }
        state.isPresentedPicker = true
        return .none
    }
}

`canAccess` implementation details

/// Definition of `canAccess`
extension DependencyValues {
    public var canAccess: FeaturePermissionHandler {
        get { self[FeaturePermissionKey.self] }
        set { self[FeaturePermissionKey.self] = newValue }
    }
    private enum FeaturePermissionKey: DependencyKey, TestDependencyKey {
        static let liveValue = FeaturePermissionHandler { feature in
            let freeFeatures = [FeaturePermissionHandler.Feature]()
            return freeFeatures.contains(feature)
        }
   }
}

public struct FeaturePermissionHandler: Sendable {
    // Nested dependency to inform app
    @Dependency(\.delegate.weakRef) var delegate
    
    private var canAccess: @Sendable (Feature) -> Bool
    
    /// Available features
    public enum Feature: String {
        case unlimitedEntries, unlimitedDates
    }
    public init(_ canAccess: @escaping @Sendable (Feature) -> Bool) {
        self.canAccess = canAccess
    }
    
    public func callAsFunction(_ feature: Feature) -> Bool {
        let canAccess = self.canAccess(feature)
        if !canAccess {
            delegate?.didTouch(.paidFeature(feature.rawValue))
        }
        return canAccess
    }
}

/// Weak reference to safely store delegate
final public class WeakRef: @unchecked Sendable {
    
    weak var weakRef: Delegate?
    
    init(_ object: Delegate?) {
        self.weakRef = object
    }
}

The alternative would be to use two dependency keys and a bit of extra code, what means more code to maintain since canAccess and delegate pattern is used on some places in the codebase.

@Dependency(\.canAccess) var canAccess
@Dependency(\.delegate.weakRef) var delegate

func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
    switch action {
    case .tappedButton:
    /// Manually triggering delegate
    guard canAccess(.unlimitedEntries) else {
         delegate?.didTouch(.feature(.unlimitedEntries))
         return .none
     }
        state.isPresentedPicker = true
        return .none
    }
}

What's your recommendation for such a use case?

[Kondamon]

I have rethought the whole issue and think the best solution is to move the access logic to the delegate and remove the canAccess DependencyKey. So, I can control the access level from within the app.

One more thing, is the WeakRef class from above a viable way to store a delegate as a DependencyKey or did I miss anything?

@Dependency(\.delegate.weakRef) var delegate

func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
    switch action {
    case .tappedButton:
        guard delegate?.canAccess(.unlimitedEntries) == true else { return .none }
        state.isPresentedPicker = true
        return .none
    }
}

[mbrandonw]

Hi @Kondamon, I haven't fully internalized the situation you are modeling, so it's hard for me to give concrete feedback.

I do want to comment on one thing, and that's this line from your original code snippet:

delegate?.didTouch(.feature(.unlimitedEntries))

We highly recommend to only call such functions from within an effect rather than directly in the reducer. You can even encourage this in your code by making didTouch async so that it's clearer that you should open an Effect.run { _ in ... } and call it within that.

In general, all interactions with the outside world should happen from within Effect.run. However, we think it's ok to make an exception for interactions that only read something from the outside world, such as Date(), UUID(), and your canAccess is also an example of that. For such simple interactions it would be a real pain if you had to run it inside Effect.run and then send it back into the reducer via an action.

But, those are the other exceptions. If an effect is making a change to the outside world, such as didTouch, then it really should go inside Effect.run. We plan on writing up an article for this in TCA to clarify this.

[Kondamon]

@mbrandonw, thanks for the hint and the clarification.

Would it be a viable option to call didTouch in the Reducer without an effect but instead fire a Task.detached { } in didTouch (outside world)? (So, I wouldn’t need to send an action back to the Reducer.)

[mbrandonw]

It isn't necessary to send an action from an effect. There are "fire and forget" effects which just executes some asynchronous work and then completes:

return .fireAndForget { 
  await delegate?.didTouch(.feature(.unlimitedEntries))
}

You should not create unstructured tasks directly in a reducer (or really even in an effect). The main reason is that you should be able to run a reducer on the same piece of state multiple times without having any affect on the outside world.