Hi @kaptain_k1rk, a great way is to inject the
RemoteSession into the
RemoteAPI object directly via initializer injection. For example in the Redux example codebase,
KooberCloudNewRideRemoteAPI takes a
RemoteUserSession in the initializer and holds on to a reference with the
RemoteAPI initializer accepts a
RemoteSession, you can inject the session in a factory method within the signed-in user’s dependency container. For instance, this would happen in
KooberSignedInDependencyContainer on line 49. Instead of initializing a fake
RemoteAPI you could initialize a real one with the
RemoteSession. This way, the
Repository classes would not need to know about
RemoteSession, just that they need something that conforms to one of the
RemoteAPI protocols. Same with the
UserInteraction classes, they wouldn’t need to know about
RemoteSession, just something that conforms to the specific
Repository protocol needed. This keeps everything nicely decoupled so that when you need to refactor the
RemoteAPI it doesn’t affect all the upstream classes.
If some requests require authentication and others do not, I would separate these requests into separate
RemoteAPI protocols. Then I’d create an
AnonymousUser dependency container and have the non-authenticated
RemoteAPIs created and stored in the
AnonymousUser dependency container. The
RemoteAPIs that require authentication would be created and stored in the
SignedIn dependency container, which contains the user’s session.
One of the goals with dependency containers and dependency container scopes is to avoid mutable objects. Using different containers for different scopes allows you to avoid needing to store a mutable user session that you would change depending on the request being made. This approach allows you to write more deterministic code that is easier to reason about.
Hope this helps. Please let me know if I can expand or explain anything else. Cheers.