Globally swapping the live value out

[jasonzurita]

Something I've been trying to translate over from the world approach to dependency management is the flexibility of globally swapping out the live value. E.g.,

struct World {
    var networkClient: NetworkClient
    ....
}

var Current = .live()

// sometime later in code to have an offline mode globally
Current.networkClient = .disabled

I came across the docs for overriding dependencies that are scoped. This is pretty neat, but not what I am looking for unfortunately.

Is this something that's possible using the Dependencies library? I assume it is, but I've been coming up short.

[mbrandonw]

Hi @jasonzurita, this is not possible with our library, and honestly it's actually a good thing that we do not allow this. Being able to globally mutate dependencies whenever you want is a recipe for uncertainty in a code base. Even with the world approach we have previously recommended people do let Current when not in DEBUG builds.

Rather than thinking about swapping out the entire dependency for a "disabled" one you should think about putting that functionality into the dependency itself, so that you can do networkClient.disable(), or something like that. Or even \.isOffline could be a dependency itself that is used inside a network client (or a wrapper of clients) to decide how to do the work.

[jasonzurita]

@mbrandonw This makes sense. I appreciate the context around the support for this functionality.

One thing that is lingering in my mind though is rebuilding dependencies due to things like: environment changes (e.g., live flipping between QA and prod), user logout/login (which would cause a cascade of changes like needing to rebuild the feature flagging system). I suppose this could be accomplished by adding API to the dependencies to "rebuild themselves" in these situations like you suggested. I did however enjoy the clean nature of throwing away dependencies and replacing them fully. This way I could avoid needing to build this kind of state management into dependencies like the network client mentioned. There was something really nice about being able to keep the clients dumb and unaware of outside state like if they were in an offline mode or not (to keep using the same example).

[jasonzurita]

Another use case that just came to mind, is debug menu functionality. I have several debug menu options like mocking the location client (e.g., playing back saved location events), changing the local live to see a language change in the app while running, and even swapping in a live mock for permission things (e.g., push notifications) so I could test out granting permissions flow without restarting the app.

[jasonzurita]

@mbrandonw I just thought of another use case (haha, sorry this has been top of mind because I am working on an architectural refactor). Previously I was able to leverage the mutability of the world to run a different kind of device farm test where we could start the app, load a fake car drive with camera and location data (the app was a dash cam app), then tell the app to start a drive. I'm not sure how this would work without building in all that state into the respective dependency entities. It was pretty nice, in this case too, to be able to cleanly throw away the live versions of dependencies for mocks on the fly.

---

All this said, maybe the answer is to start/restart the root of the app using the withDependencies function. Then we could replace the dependencies for that run of the app each time. This might be a bit awkward though. We'd have to start the dependencies library up with a dependency to begin with that we'd never actually end up using. Also, I'm not totally sure if this would even work the way I'm thinking.