Overriding dependencies outside the scope of the ReducerProtocol (e.g. UIButton extension)

[acosmicflamingo]

Great job with decoupling Dependencies from TCA! Looking really good :D I do have a question though.

Let's say I have a function within a UIButton extension that uses Combine to update the title font whenever @dependency fontMangager.appFontPublisher sends a value down stream:

extension UIButton {
  func adaptiveFont() -> AnyCancellable {
    @Dependency(\.fontManager.appFontPublisher) var publisher: AnyPublisher<MyFont, Never>

    return publisher.sink {
      // Logic that updates button font
    }
  }
}

Let's also say that these buttons are generated deep within a UIKit app that is all powered by TCA. I would assume that overriding the dependencies here would be reflected in the adaptiveFont function:

final class AppDelegate: UIResponder, UIApplicationDelegate {
  let store = Store(
    initialState: AppMainReducer.State(),
    reducer: AppMainReducer()
      .dependency(\.fontManager.appFontPublisher, {
        print("Oh hi there!")
        return Just(.Ubuntu).eraseToAnyPublisher()
      })
  )

Specifically, I expect to see the "Oh hi there!" message appear in the console because I was overriding that dependency within a very high-level reducer. However, I only see that the live value is being used. Am I just really abusing @dependency here? While I can certainly override the dependencies with "withDependencies", to me it makes more sense to override all dependencies in the same place instead of searching for the UIButton extension, finding the adaptiveFont function, and overriding it in there. Perhaps I'm missing something silly?

[mbrandonw]

Hi @acosmicflamingo, what you are trying to accomplish is not immediately possibly unfortunately. And the reason it is not possible is because dependencies are built on the back of @TaskLocal which has very strict rules for how you are allowed to change a value.

I highly recommend you read the following articles from the documentation to get a deep understanding of why:

• Overriding dependencies
• Lifetimes
• Single entry point systems

So, it's not a limitation of the library, but rather a core tenet of how the library is designed.

When you access @Dependency from the UIButton, you are doing so in a scope that is completely untethered to the scope where the original dependencies were set, and so it must default back to the liveValue. The .dependency(...) you used in the entry point of the app can only set the dependencies for the reducer, but nothing outside that scope.

The only for your UIButton to see the dependency changes made at the entry point is if you have a chain of withDependencies that tie the call site of the UIButton all the way back to the entry point. That can be a lot of work to do, and may seem annoying, but it is what allows the dependency management library to be safe to use and not surprising.

[acosmicflamingo]

Thanks @mbrandonw! Yes that all definitely makes sense. Well...I suppose I now have two ugly solutions to choose from for supporting dynamic font in my UIKit app: either using "withDependencies" that tie the UIButton call site back to the entry point, or scope userSettings to every single microfeature state so if a font were to update, all buttons and views would update accordingly. I hate both approaches but since I'm doing it all in UIKit (where ViewModifiers or @Environment do not exist), I don't have a choice :( unless of course there's a 3rd option you may see that I don't (and please don't say "the solution is to build it in SwiftUI" LOLOL) :)

[acosmicflamingo]

Now that I've spent more time thinking about it, perhaps I'm too focused on a corner case that I'll never really encounter myself. After all, I'll never need to overwrite the app font in the high-level reducer like other dependencies.

Although Preview support might be harder to do with the way I implemented the adaptiveFont function, the real concern I had was testing. Thanks to how Dependencies is designed, I can successfully override dependencies for the model I'm interested in testing and everything works as expected:

final class FontManagerTests: XCTestCase {
  func testAdaptiveFont() {
    var cancellables = Set<AnyCancellable>()
    let font: FontFamily = .ComicSans
    withDependencies {
      $0.fontManager.appFontPublisher = {
        return Just(font).eraseToAnyPublisher()
      }
      // Added this here because Dependencies caught that this dependency is also being used
      // and not adding this resulted in an Unimplemented error
      $0.fontManager.boldTextEnabled = {
        false
      }
    } operation: {
      let button = UIButton()
      button.setTitle("Test", for: .normal)
      let cancellable = button.adaptiveFont(textStyle: .footnote, weight: .regular)
      cancellable.store(in: &cancellables)

      XCTAssertEqual(ha.titleLabel?.font.familyName, font.familyName)
    }
  }
}

Neat-O!

[mbrandonw]

Hi @acosmicflamingo, I think you stumbled upon an important part of using the dependency library.

If your dependency really only has a live value and a test value, and if you don't need to "scope" dependencies for one portion of the app, then it is totally fine to use it how you are. You get instant access to the dependency anywhere in your app, and you can wrap all of your test code in withDependencies to test any code using the dependency.

The dependency scoping stuff is an advanced feature that doesn't always need to be used.