Updating Dependencies at a later point in the app's lifecycle #2935
Replies: 4 comments 12 replies
-
|
I think Maintainer gave similar advice in the Slack the other day:
|
Beta Was this translation helpful? Give feedback.
-
|
I already included it in the project: I'll branch the repo with a ReducerReader variant |
Beta Was this translation helpful? Give feedback.
-
|
Hi @LucasVanDongen, thanks for taking the time to create a project with many different styles of dependencies. However, your project does not currently compile due to a missing Package.swift. Can you update it so that it compiles? |
Beta Was this translation helpful? Give feedback.
-
|
Somehow my local Package.swift wasn't included? My apologies, didn't do a clean clone check because I didn't consider the repo ready yet. Pushed it, tested it, seems to be working now. |
Beta Was this translation helpful? Give feedback.
-
|
I've got it working like this: struct Features: Reducer {
@ObservableState
enum State {
case logIn(LogInFeature.State)
case authenticated(AuthenticatedFeature.State)
}
enum Action {
case logIn(LogInFeature.Action)
case authenticated(AuthenticatedFeature.Action)
}
var body: some Reducer<State, Action> {
CombineReducers {
Reduce { state, action in
switch action {
case let .logIn(.authenticatedSuccessfully(token)):
state = .authenticated(AuthenticatedFeature.State(token: token))
return .none
case .logIn:
return .none // Ignore the rest
case let .authenticated(.authenticated(token)):
state = .authenticated(AuthenticatedFeature.State(token: token))
return .none
case .authenticated:
return .none
}
}
ReducerReader(reader: { state, action in
switch state {
case .logIn:
Scope(state: /State.logIn, action: /Action.logIn) {
let store = Store(initialState: state) {
self
}
LogInFeature(parentStore: store)
}
case let .authenticated(state):
Scope(state: /State.authenticated, action: /Action.authenticated) {
AuthenticatedFeature()
.dependency(\.userManager, UserManager(token: state.token))
.dependency(\.storyFetcher, StoryFetcher(token: state.token))
}
}
})
}
}
}However, the only feature that has these overwritten values is So I see the following in may app when I run it: 
...but I'm going to take a break from this and take a fresh breath. The progress up to this point is in the following branch / commit: LucasVanDongen/SwiftDependencyInjectionCompared@82f2e10 |
Beta Was this translation helpful? Give feedback.
-
|
Hey @LucasVanDongen, thanks again for taking the time to put this project together. It definitely helps us understand how you are approaching dependencies in a variety of ways. There is a lot to respond here, so it's tough to know where to start. Let me start with some basics: First, I really like that you have built the same tiny app using a variety of dependency styles. This makes it easy for people to study the differences and even contribute their own styles. However, the project still doesn't really compile cleanly on its own. I would recommend making all the projects iOS instead of macOS so that people don't have to mess with app signing, the Package.swift needs to target iOS 17+, and I recommend using https for git packages rather than SSH (it's more portable). Also, the needle project still doesn't build. I needed to comment out the Second, you mentioned previously that a goal is to have the concept of a dependency that is somehow unavailable until the user authenticates. I believe that is what the However, most of the projects don't actually demonstrate that capability. You can create The only ones that do have this behavior are "PassedDependencies" and NeedleDependencies", but in each of those projects the dependencies are just being passed around explicitly. I must admit, I don't really understand what needle is accomplishing in this project. It seems to be quite a bit work, and doesn't play nicely with Swift concurrency warnings or SwiftUI. And finally, I have rebuilt your demo app using just our swift-dependencies library and vanilla SwiftUI. I'm not using TCA at all because it's really not necessary to get the benefits of dependencies. Here's the diff with your I tried my hardest to keep the overall app structure true to what you have in the other apps. So I didn't change the dependencies at all, or the logic in the features, but I do think there is more room for simplifications and improvements. There are some interesting things in this new SwiftDepedencies app target, and a few of the problems pointed out in your comments have actually been fixed. For example, in the environment style of dependencies you run the risk of forgetting to set up dependencies in the view hierarchy, resulting either in the wrong dependency being silently used, or a loud crash. In particular, you need to make sure to do this: AuthenticatedView()
.environment(\.userManager, UserManager(token: token))
.environment(StoryFetcher(token: token))…when the app flips to an authenticated state. But also even this isn't ideal, because this only works (as you noted) for stateless dependencies, which is probably not super common. This is solved in the SwiftDependencies project by creating the state = .authenticated(
withDependencies(from: self) {
$0.userManager = UserManager(token: token)
$0.storyFetcher = StoryFetcher(token: token)
} operation: {
AuthenticatedModel()
}
)This statement runs only a single time, at the moment the app switches to authenticated mode. It doesn't matter how many times the view re-draws itself. Further, these dependency changes are propagated deeply into the app but in a tree-like fashion. The dependency overrides are only active for As another example of a downside, in the Factory demo you have the following comment: …with regards to these lines of code: // First assign the dependencies
AuthenticatedDependenciesManager.handle(token: token)
// Then flip the UI switch
state = switch token.isEmpty {
case true: .loggedOut
case false: .authenticated(token: token)
}And this definitely is subtle. The SwiftDependencies project also fixes this problem, and with the same lines I pasted above: state = .authenticated(
withDependencies(from: self) {
$0.userManager = UserManager(token: token)
$0.storyFetcher = StoryFetcher(token: token)
} operation: {
AuthenticatedModel()
}
)This simultaneously populates the state to drive the navigation in the view and overrides dependencies for that child feature. There is no two-step process to get out of order because there is no global, mutable singleton. Everything is held in a Next you have a few comments about the various "placeholder" dependencies you have: // This implementation is used to prevent a `nil` value for this dependency while the user is not authenticated yet
…
// You have an issue if this function would actually be called
…
// If this function would ever be executed, we have a problemAnd these comments are just purely aspirational right now. It is completely possible to accidentally use these placeholder dependencies in the environment and Factory projects. Our swift-dependencies library also solves this problem. When registering the dependency with the library you can provide only a struct TestStoryFetcher: StoryFetching {
func fetchStories() async throws -> [Story] {
return []
}
}
private enum StoryFetcherKey: TestDependencyKey {
static let testValue: any StoryFetching = TestStoryFetcher()
}However, crucially, if this dependency is accessed in a "live" context (e.g. simulator or device), then a runtime warning will be emitted in Xcode letting you know that the dependency must be overridden. For example, once the user is authenticated, what if we forgot to override the state = .authenticated(
// withDependencies(from: self) {
// $0.userManager = UserManager(token: token)
// $0.storyFetcher = StoryFetcher(token: token)
// } operation: {
AuthenticatedModel()
// }
)Go ahead and try it out in my fork. You will find that once you get to the authenticated screen you immediately get purple runtime warnings in Xcode letting you know that the dependencies have not been overridden: 
It's worth comparing this to your environment-based project, which will crash if you don't override the dependencies, or the Factory-based project, which will use a placeholder dependency with no warning. And it technically is possible to structure dependencies in a way with our library that allows you to gain access to a dependency only after the user authenaticates, but it doesn't come for free (just as it doesn't come for free with the PassedDependencies or NeedleDependencies projects). We should get some documentation on this technique so that it can be publicly known. Sorry this post was so long, but hopefully it helps a bit. And I specifically did not want to talk about TCA because I feel the discussion is about dependencies in general, and really doesn't have anything to do with TCA. However, all of the ideas mentioned above do work with TCA just fine. I did look at your branch a bit, but I can say that you definitely should not approach the problem that way. You should never hold onto a |
Beta Was this translation helpful? Give feedback.
-
Isn't this true of Needle too? When the token is acquired from the case let .authenticated(token):
let authenticatedComponent = rootComponent.authenticatedComponent(token: token)
return AnyView(authenticatedComponent.authenticatedView)But if you needed to navigate to another view from
I'm not sure I understand how that is possible in practice, and I don't see it being demonstrated in the demo project. Right now one only gets a authenaticated dependency by passing a token to a method on
But as always, there are trade offs. Our swift-dependencies library is the only one out there (afaict) that truly offers tree-based propagation of dependencies without manually passing dependencies around, but at the cost of remembering to use At the end of the day, there is no magical solution to dependency injection. It's always a push-pull relationship between safety and ergonomics (I talk about this here if you are interested in more details). Explicitly passing dependencies is the safest and least ergnomic, whereas a global, mutable singleton is the least safe yet super ergonomic. Our dependencies library tries to be somewhere in the middle. It is safe due to its use of |
Beta Was this translation helpful? Give feedback.
-
NeedleThe real difference with Needle is that you don't need to pass forward anything once it's in the tree. Here's an example of the extension AuthenticatedComponent: AuthenticatedViewBuilding {
var authenticatedView: AuthenticatedView {
AuthenticatedView(
logInSwitcher: dependency.logInSwitcher,
component: self
)
}
}It finds the It first needs to ask for that dependency through it's protocol: protocol AuthenticatedDependency: Dependency {
var logInSwitcher: any LogInSwitching { get }
}This private class AuthenticatedDependencycda53ef9a0d1fafe1614Provider: AuthenticatedDependency {
var logInSwitcher: any LogInSwitching {
return rootComponent.logInSwitcher
}
private let rootComponent: RootComponent
init(rootComponent: RootComponent) {
self.rootComponent = rootComponent
}
}So if my If you don't set up the required dependency in any of the Components toward the root, the build step that generates the could will output an error like this: You still need to maintain an hierarchy of Components that are created by Components so they can pass along all of the dependencies closer to the root, so it's basically a Nested Factories Pattern with a bit of help to remove the boiler plate. withDependenciesI really like the idea of seeing purple warnings when I miss to propagate a properly overridden. I don't see a way to do it better than that when you use a Service Locator type of approach and don't sneak in a build step. I am going to include an example of this. And remember that in the end when |
Beta Was this translation helpful? Give feedback.
-
|
Hi @LucasVanDongen, thanks for taking the time to explain more about Needle. That definitely helps me understand more, and I was even able to get the However, I still fail to really see what value all of this machinery is bringing. It seems to only bring a slight amount of safety and ergonomics to managing dependencies. Now I fully admit that I may just not understand all the moving parts of Needle, so here's a very concrete example. Suppose I wanted to be able to navigate to a "settings" view from the "authenticated" view, and the settings view wants access to the As far as I can tell, one way to start is define a new dependency protocol for all the things the settings feature wants access to: protocol SettingsDependency: Dependency {
var logInSwitcher: any LogInSwitching { get }
}Now one interesting thing already here is that I cannot specify protocol SettingsDependency: Dependency {
var logInSwitcher: any LogInSwitching { get }
var userManager: any UserManaging { get } // 🛑
}This is because the Speaking of which, next I can define a component for the settings feature like so: class SettingsComponent: Component<SettingsDependency> {
var userManager: any UserManaging {
return shared { UserManager(token: token) }
}
let token: String
init(
parent: Scope,
token: String
) {
self.token = token
super.init(parent: parent)
}
}Now we can express that we want the Moving on, we next define a way to derive a extension AuthenticatedComponent {
func settingsComponent(token: String) -> SettingsComponent {
SettingsComponent(parent: self, token: token)
}
}And this is what the Next we can create a struct SettingsView: View {
let component: SettingsComponent
var body: some View {
Form {
Text("Token: \(component.token)")
Button("Logout") {
Task {
await component.logInSwitcher.loggedOut()
}
}
}
}
}And finally, from the .popover(isPresented: $isPresented) {
SettingsView(
component: component.settingsComponent(token: component.token)
)
}I personally think that is actually quite a bit of code to accomplish something so simple. Also, dependencies are being passed around, whether you like it or not. The And maybe all of this ceremony seems to bring some kind of safety to the situation in that you are not allowed to construct the settings component unless you have a .popover(isPresented: $isPresented) {
SettingsView(
component: RootComponent()
.authenticatedComponent(token: "deadbeef")
.settingsComponent(token: "deadbeef")
)
)
}Not even the It's worth pointing out what the equivalent looks like in the swift-dependencies version of the app that I linked to above. You would start by defining an observable object that declares its dependencies using @Observable
class SettingsModel {
@Dependency var userManager: any UserManaging
@Dependency(\.logInSwitcher) var logInSwitcher
init(token: String) {
_userManager = Dependency(\.[userManagerForToken: token])
}
…
}You define the view that uses the model: struct SettingsView: View {
let model: SettingsModel
…
}And you present the settings view from the authenticated view: .popover(isPresented: $isPresented) {
SettingsView(
model: SettingsModel(token: model.userManager.token)
)
}And, that's it. And I don't think this is any less safe than Needle, but it's definitely a lot more ergonomic. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for (again) leaving you for an answer for such a long time, but I had some severe issues to get Needle to co-operate with me. There is something to be said about great documentation. Did you know that Needle needs you to declare every dependency you want to share up the hierarchy Notice the complete absence of the word I'm not sure if that example would even work? But enough for my frustration, let's take a look what I finally got working: This is a very remote protocol RemoteDependency: Dependency {
var token: String { get }
var logInSwitcher: any LogInSwitching { get }
}
class RemoteComponent: Component<RemoteDependency> {
func primaryThing() -> String {
"\(dependency.token)"
}
func buildAnotherThing() -> String {
"\(dependency.logInSwitcher)"
}
}It looks like this in the generated code: registerProviderFactory("^->RootComponent->AuthenticatedComponent->AnotherComponent->RemoteComponent", factory08e4610575c96545f557751f3184f163fec4c128)So there's
class RootComponent: BootstrapComponent {
public var logInSwitcher: any LogInSwitching {
shared { LogInSwitcher() }
}
```
`AuthenticatedComponent` defines the `userManager`:
```swift
class AuthenticatedComponent: Component<AuthenticatedDependency> {
public var userManager: any UserManaging {
shared { UserManager(token: token) }
}
Everything else is handled by the generated code, and by the fact that Needle is able to trace the chain of parents to the node that actually declares it. Obviously in a more complex real-life scenario the But it's not necessary to create every instance of for example the ####Back to your example Once class AuthenticatedComponent: Component<AuthenticatedDependency> {
public let token: String // From here on, we can access this token in any child component
init(parent: Scope, token: String) {
self.token = token
}
var settingsComponent: SettingsComponent {
SettingsComponent(parent: self)
}
}we need to adjust the protocol a little bit protocol SettingsDependency: Dependency {
var logInSwitcher: any LogInSwitching { get }
var token: String { get } // this MUST exist as a `public var` in the `AuthenticatedComponent` (or any other parent)
}...and then we can build Reduction of complexity and riskWhen the amount of nested components grows, the complexity and/or risk of many other solutions grows exponentially, because either these components / features either need to know about what all of their child nodes need (like nested Factories), or could inadvertently break a child node without knowing (the When I maintained a widget somewhere deep inside the booking process in Booking.com, we had another team inadvertently cut one of our passed dependencies because they were replacing a certain piece of the booking process and had absolutely no warning we were no longer able to execute network requests. It was something we carried over from right from the start of the booking process to the end, but could not be created without starting a booking first, so it wasn't a service type of dependency. So while their experiment slowly rolled out, we saw our sales drop slowly, initially thinking "just a bad day?" until it was abnormally low the next day. Lost sales and lost productivity as the other team had to roll back, fix, test, and redeploy while we spent time finding the issue and helping them fix it. Needle would have:
|
Beta Was this translation helpful? Give feedback.
-
|
Hi @LucasVanDongen, thanks again for taking the time to look into all of this. That The sequence of steps to build the settings feature I outlined above only slightly changes with your new found information: Start by constructing a dependency protocol to list out everything you need: protocol SettingsDependency: Dependency {
var logInSwitcher: any LogInSwitching { get }
var userManager: any UserManaging { get }
var token: String { get }
}(Let's also assume that Then you define your class SettingsComponent: Component<SettingsDependency> {
}And then you define a computed property on extension AuthenticatedComponent {
var settingsComponent: SettingsComponent {
SettingsComponent(parent: self)
}
}And then everything proceeds as before. You define a But most importantly, you are explicitly passing a value through the feature hierarchy. It's just abstracted as this component thing that inherits from other components. But the component is what grants you access to the dependencies, and there is no way around passing it to any feature that needs dependencies. And so in my opinion that isn't much different from simply passing along some kind of token that grants access to dependencies as I showed in the swift-dependencies demo of my fork: @Observable
class SettingsModel {
@Dependency var userManager: any UserManaging
@Dependency(\.logInSwitcher) var logInSwitcher
init(token: String) {
_userManager = Dependency(\.[userManagerForToken: token])
}
…
}No need to define a separate protocol just for settings dependencies, no need to rely on build tools and their quirks, but you get all the same safety. Child features do not need to pass along dependencies (except for
FWIW, these concerns are not an issue with our swift-dependencies library. Child features get to declare what dependencies they need to do their job, and parent features can be completely oblivious to that. The only time a parent feature needs to care about what a child depends on is when the child uses a dependency that needs a token to access, and then it must pass along that token. But this really is no different than Needle. You are still passing around components that hold a token on the inside. Needle's CLI tool may cause build failures when it detects a token by used in the incorrect way, but you also get that for free with passing a token around to features like in
I agree the situation you outlined at your work is definitely the nightmare scenario of dependencies. We just think that there are simpler solutions to that problem than what Needle proposes. But, can you explain how Needle avoids passing something through the feature hierarchy? That isn't demonstrated in your sample project, e.g. a |
Beta Was this translation helpful? Give feedback.
-
I'm investigating TCA in general and its dependency management in general. In general everything clicked together pretty well but I have trouble switching from log in to authenticated state. The authenticated state has several dependencies that can only work when a token is present.
While I understand there are ways to work around it, like updating a static dependency with the token and clearing it out again when logging out I would like to figure out if it's possible to update the dependency later on, so they will automatically disappear again when the AuthenticatedFeature ends when the user logs out. There are also other more complex scenarios imaginable where you really want to change behavior of a dependency depending on where you are in the application.
According to the docs I should use
.dependencyto change them, but withifCaseLetI cannot access that token:I tried using the yet-to-be-merged
ReducerReaderfeature, but I got stuck doing the implementation as the branch seems to be outdated and the examples were not complete working examples.I think it was the way though.
The whole repo can be found here
Can somebody lend me a hand with this?
Beta Was this translation helpful? Give feedback.
All reactions