Dependencies without Reducers

[JimRoepcke]

Is the dependency system designed to only be usable in TCA contexts?

I'm curious if we could use @Dependency throughout our legacy / UIKit app as well as in TCA features.

Thanks!

[mbrandonw]

Hey @JimRoepcke, this is a great question, thanks for bringing it up.

We will actually get into this topic very briefly in later eps of the protocol series, but essentially we do feel that the dependencies system could be extracted into its own repo some day (that's one reason why we have it as a separate library in the package).

However, it comes with some caveats. While it could power the dependencies for other kinds of applications, such as vanilla UIKit/AppKit/SwiftUI, it cannot have the all the features and ergonomics that it does with TCA.

One of the more interesting aspects to how TCA is designed is that it gives a single entry point into an application's logic, which is reduce(into:action:). There are a few subtleties to consider, such as effects feeding back into the system, but the Store can coordinate that to help ensure a fully closed system.

This is also true of SwiftUI views. There's only one way to create a view, and that is the body property, and that is exactly why @Environment is so nice to use. It's also true of most web frameworks. Deep down there's usually just a single response function that needs to be implemented to turn URL requests into HTTP responses.

Because all of these systems have a single entry point, you can do incredible things such as change the dependencies for a well-defined scope, run code in that scope, and then revert the dependencies once the scope ends. And only the code run in the scope will see the updated dependencies. Nothing outside will.

For example, in the new protocol style we can override a dependency for just one child reducer (and all of its children), by running the child reducer inside a task local's withValue.

This is not possible at all with a vanilla UIKit/AppKit/SwiftUI application because there is no single entry point to a feature's logic. For example, you can have an ObservableObject conformance that exposes tons of methods for various behavior in the feature. So, scoping dependencies in these kinds of applications becomes more complicated, and is why there are lots of DI frameworks out there a lot more complicated than what we are doing for DependencyValues.

But, if you don't need dependency scoping in your application, then this system could work for you. You would still every once in awhile run into some rough edges. For example, in tests if you wanted to run an ObservableObject model in a controlled environment, it would need to look something this like:

func testBasics() async {
  let model = FeatureModel()

  let dependencies = /* set up test dependencies */

  await DependencyValues.$current.withValue(dependencies) {
    await model.recordButtonTapped()

    XCTAssert(…)

    await model.stopButtonTapped()

    XCTAssert(…)
  }
}

One thing cool here is that as long as your model stays in the world of structured concurrency, you will be able to run its logic in a fully controlled environment. That wouldn't have been possible before Swift's concurrency tools.

So, in conclusion:

• We think the Dependencies module could be broken out, as-is, and it would be immediately useful to other single entry-point, closed system frameworks, including web frameworks.
• We also think we could possibly do a little extra work to make it a bit nicer for non-single entry-point frameworks, and we may explore that someday soon.

[danieleformichelli]

Hi @mbrandonw! 👋
Has there been any progress on this? do you still plan to publish Dependencies as a separate package? It would be super useful! 🙏

[mbrandonw]

We do still plan on it, but we're not sure exactly when yet.

Out of curiosity, are you encountering any problems by depending on TCA directly and using Dependencies from it? That should be completely fine to do.

[danieleformichelli]

No specific problem, but as we are working on some libraries, we would avoid them depending on the whole TCA package.

The main reasons why we would like that is:

• having a smaller dependency, and hence faster checkout time when opening Xcode
• not having to bind our library to a TCA version, given that we don't actually depend on it

[davdroman]

A small item on my wishlist for a separate library would be to name it Dependency, as currently import Dependencies reads as "import all dependencies in the project".

[tgrapperon]

@davdroman I was hoping you could use the new module aliasing SwiftPM feature to fix this on your side, but I can't make it work apparently (it complains about non-swift sources in DependenciesTest, which is very odd).