Dependencies that depend on dynamic values

[martin-muller]

Hi, we've encountered an interesting dependency modeling issue and we'd love to hear opinions of the community!

Our discussion might be related to #1287, can move our findings there if preferred.

Our app's network stack needs to hit different urls based on the user that's logged in and the app needs to be able to logout and log back in during its lifetime. We have a mix of in house api layers and layers that rely on third party libraries that we don't fully control, but all expect url at the time of initialization. This previously wasn't an issue because clients were created either after login or at the point of reducer creation, but since dependency values are static vars, it's now something we need to keep in mind.

Options we've came up with so far:

1. Use the _DependencyKeyWritingReducer higher order reducer

   This might the easiest solution, but since our newer TCA-based features need to integrate with our older coordinator based app we would need to "override" the dependencies in many places and we can't be sure at compile time, that feature is using the correct dependency. We can alleviate this down side by not implementing live values on dependencies that depend on session lifecycle, which would warn us at run time when developing feature that uses such client and by requiring said clients at reducer init, so we can't forget to supply the correct client at point of creation. Static analysis could also help us with this option, but it doesn't seem feasible at the moment.

2. Handle url change internally in network clients

   I think this is generally pretty good solution and one that the built-in dependencies use (Calendar.autoupdatingCurrent for example), however I'm not sure its ideal for our use case. Adding this capability might require large changes and big portion of the app doesn't currently need such functionality.

3. Wrap client in object that handles resetting

   @dynamicMemberLookup
   @propertyWrapper
   final public class Session<WrappedValue> {
       public typealias Initializer = () -> WrappedValue
   
       private var initializer: Initializer
       private var _value: WrappedValue
   
       public init(_ initializer: @escaping @autoclosure Initializer) {
           self.initializer = initializer
           self._value = initializer()
           
   		 // When new url is fetched (listen with notification for example), invoke initializer and assign to _value
       }
       
       public var wrappedValue: WrappedValue {
           get {
               self._value
           }
           
           set {
               self._value = newValue
           }
       }
       
       public subscript<Value>(dynamicMember keyPath: KeyPath<WrappedValue, Value>) -> Value {
         self.wrappedValue[keyPath: keyPath]
       }
   }

   With this approach I like the composability: any client can be tied to the life-time of a session, separation of concerns: session can be contained only to dependencies and rest of the app can continue using clients as they did before and the ease of use for consumers of such client: if client only provides Session<APIClient> through the dependencies system, consumers don't need to worry whether they're using the correct client or if they need to handle some action when urls change. It does however come with a decrease in ergonomics, if dependency uses unapplied instance method, which is unsupported by key paths, the user needs to add another property wrapper, which requires better understanding of the issue.

For now we went with option 1, we found it the easiest to grasp, but we're wondering what does the community think.

[alexito4]

On Option 1:

We've been using option 1 for a while and have some ground rules to make it a bit nice:

• Don't implement liveValue for a dependency (this will give a runtime warnings if you forget to overwrite it)
• Make the entry point of your Feature accept the dependencies on the init (this lets the compiler remind you need ot inject these session dependencies on your feature, which avoid the runtime warning mentioned above)
• In your root Feature domain use dependency to overwrite the dependency with the one injected in the init.

But it still requires PR reviews to be very attentive. If a new feature is implemented and doesn't follow this rules it will be problematic.

So we're still open for better suggestions ^^

[alexito4]

On Option 2:

Reading again the linked discussion it seems that is suggested (or at least not frowned upon) that dependencies handle the state internally.

See #1287 (comment)

you could have an APIClient in your environment that is either logged-in or logged-out and manages this mutable state internally, and you can manage loading logged-in state either inside your reducer (via applicationDidFinishLaunching or sceneDidChange), or outside your reducer (via an injected .dependency).

If this state is internal to your dependency, we see no reason to manage it in app state. If anything, we think the dependency should manage it, and if a screen needs to render it in some way, the dependency should expose a way to fetch or subscribe to the latest value.