Late feedback on swift-composable-architecture

[mackoj]

Hi 👋,

Thanks for making TCA, I have been using TCA since its public beta and enjoyed it a lot. This library has a lot of great ideas and features to improve it I will focus only on the issues that I face using it. I have implemented a few apps using it in the last few years. I have used this every day since its launch.

FWIW I use TCA today in app that is in production and have around 100 modules.

The main issues I face are regarding Environnement, Routing / DeepLink / Navigation and Async/Await/StructuredConcurrency support limitations(in no particular order). Some of the issues are related to the limitations of Swift itself but I feel that I have to talk about them since I face them. Since its launch, a lot has changed and a lot of issues I use to have disappeared.

I’m not a native English speaker please forgive the spelling mistakes and not appropriate tone.

Environnement

When you have multiple layers of reducers you have to change each of them if a leaf feature has a new need from the environment. Changing each parent layer is cumbersome and muddy the understanding of what each layer truly needs which is forcing you to make a spin-off environment for each parent layer that contains only what it needs.

Ideas to improve this:

• un-coupled env with the reducer scoping mechanism
• use TaskLocal to store and share the environment
• Thomas Grapperon experimented with an alternative approach in https://github.com/tgrapperon/swift-composable-environment
• using a super singleton to control the world
• proto branch 🤷‍♂️

For example, the dashboard feature only needs the content of LocalDashboardEnvironment for its reducer but child reducers need other stuff from the env so he has to have them too in the DashboardEnvironment. When you have a lot of layers it is cumbersome to add a property to all parent env.

public struct DashboardEnvironment {
  var logger: Logger
  var token: TokenClient
  var compatibleProjects: CompatibleProjects
  var bitrise: BitriseClient
  var mainQueue: AnySchedulerOf<DispatchQueue>
  var feedback: FeedbackClient
  var localNotifications: LocalNotificationClient
  var isPro: () -> Bool
  var application: UIApplicationClient
  var log: LogClient
  var donwloader: GenericDownloaderClient
  var bitbot: BitbotClient
  var date: () -> Date
  var maximumNumberOfLinesCropForFailureReviewErrors: Int
  var bitriseBuildURL: URL
  var favoriteArtifactsStateFilePath: () -> URL
  var cicd: CICDClient
  var dataStore: CICDDataStoreClient
  var bookmarkedProjectsFilePath: () -> URL
  var settingsFilePath: () -> URL
  var downloadDataStoreClient: DownloadDataStoreClient  
}

public struct LocalDashboardEnvironment {
  var logger: Logger
  var token: TokenClient
  var compatibleProjects: CompatibleProjects
  var bitrise: BitriseClient
  var mainQueue: AnySchedulerOf<DispatchQueue>
  var feedback: FeedbackClient
}

Async/Await/StructuredConcurrency

Today we only have .task and it is not enough when we need to send multiple actions/effects or none is not possible.
How to properly handle client that send AsyncSequence data?
Should each reducer have a TaskGroup to execute its actions?
Should the State be expected to be Sendable?
How does .receive(on: env.mainQueue) interact with Actor?
Maybe .task should send back an Effect?

// This can be fixed by adding a none case to .DashboardAction but I don't feel like it a great way to fix it.
// Type 'DashboardAction' has no member 'none'

  case .onAppear:
      return .task {
        return .none
      }

// if the logic in the task is complex we need to work around the lack of concatenate/merge

      return .task {
        return .concatenate / .merge
      }.receive(on: env.mainQueue)
        .eraseToEffect()
        .map(.blablabla)

A lot of users on this forum talk about it and build a lot of libraries to try to fix this missing piece.

Routing / DeepLink / Navigation

Having swiftui-navigation working with TCA.
A lot of users on this forum talk about it and build a lot of libraries to try to fix this missing piece.

Libraries that have tried to fill this hole:

• https://github.com/rcarver/composable-presents
• https://github.com/johnpatrickmorgan/TCACoordinators
• https://github.com/darrarski/swift-composable-presentation

Large State

This one happens to me at least once a year but it takes me a long time to fix it each time. When we have a state that grows too much in size we will have a stack overflow. I don't know if it is possible but can this be fixed at the library level?

Ideas to improve this:

• provide a CopyOnWrite property wrapper in TCA
• provide more education around this issue(documentation)
• having hooks in TCAs guts to be able to more quickly identify where to apply a fix in case of a crash
• push the community to ask Apple to provide a fix for this

People talking about this:

• https://forums.swift.org/t/large-structs-and-stack-overflow/44820
• Potential for stack overflow with large app states #488
• Crash on startup since 0.24.0 #752
• Crash in Store.send #1098

Questions

• Adding throwing capabilities to reducer: (inout State, Action, Environment) throws -> Effect<Action, Never>. It might not be possible due to Swift's limitation on rethrow but let's ask anyway.
• How to properly signal in an action that you have that there are cases that should not be public? I know that this is a Swift limitation and not on TCA, but in complex reducers, I end up with a _private(PrivateAction) to signal to others that this should not be called or relied upon externally of the module.

I have been meaning to write this for a long time sorry for the delay.

Thanks,

[mbrandonw]

Hey @mackoj, thanks for the detail post! Lots of great questions and ideas in here.

There's a lot to respond to, and I don't have time to go fully in depth on all of it, but I can give some insight into what we are thinking and our plans for the future. Some of these topics could probably be split into separate discussions to get more focused feedback from the community.

Environnement

Definitely agree with everything you say here, and we do have plans to address soon. You linked to your past discussion about our "proto" branch, and we just want to say that it's not an abandoned experiment. We've been playing with it for many months to figure out all the subtleties of it, and we realized that it actually requires a new Swift feature to make it fully viable. In particular, once we have SE-0346 we will be able to smooth over all the rough edges we found in the proto branch, which you can see in our new proto-2 branch 😅

We will have to wait until Swift 5.7 releases to support this, but we are really excited to move in this direction.

Async/Await/StructuredConcurrency

We also agree with a lot of what you say here. We have some experiments of how we want to slowly evolve TCA to be fully driven by Swift concurrency, and drop all Combine dependencies (except for when needing to interact with SwiftUI).

This is going to be a longer, slower process because there will most likely need to be breaking changes along the way. We will be starting with introducing more tools to Effect, ViewStore and TestStore that allow for deeper integrations with Swift concurrency. You can see our current experiments here. Then sometime later we will start weening the library off of Combine and have everything powered by the new concurrency tools.

The main reason we have been taking it slow adopting concurrency tools in TCA is testing. Our top priority with TCA is to make testing always easy to do and deterministic. Unfortunately, Swift's concurrency tools introduce a lot of non-determinism in code, and we are struggling to control that. We started a forum post to demonstrate the problems we are seeing and see if anyone knows how to reliably test concurrent code. So far there hasn't been much movement, but it's something we are actively investigating.

Here are some more details on each of your questions:

Today we only have .task and it is not enough when we need to send multiple actions/effects or none is not possible.

Soon we will have Effect.run { send in ... } that provides an async context from which you can send multiple actions.

How to properly handle client that send AsyncSequence data?

You will use Effect.run to do this, but such code will be tricky to test due to the non-determinism referenced above.

Should each reducer have a TaskGroup to execute its actions?

Maybe, but from our early experiments of writing a slim TCA with no Combine we did not find this was necessary.

Should the State be expected to be Sendable?

State should typically be implicitly sendable by virtue of the fact that it's a struct and it should only contain other sendable things. We do think that environments/dependencies will need to be sendable in order to be accessible from things like .task {} and .run {}.

How does .receive(on: env.mainQueue) interact with Actor?

For a live main queue it just does what you would expect it to do, but in tests with a test scheduler or immediate scheduler it has some non-determinism problems. You will need to do extra await Task.yield()s in order to push the task forward so that you can make assertions.

Maybe .task should send back an Effect?

This shouldn't be necessary with Effect.run.

Routing / DeepLink / Navigation

We have a lot of experiments dealing with this too, largely inspired by our discoveries from our swiftui-navigation library. You can check out this old branch to see some of the ideas, but we have actually refined them quite a bit since then, just not in any public place.

Large State

Yeah this one is a bummer. We might need to ship a PW to deal with this, but it also seems like Swift could improve. It's been mentioned in the past the Swift could potentially detect when a value blows past the stack size and then automatically box it up on the heap.

At the very least we should have some documentation on this to point people to.

It's also worth mentioning that our experiments on proto-2 will help with this because composing large reducers with protocols instead of closures will lead to much smaller call stacks, and hence less data being copied around.

Adding throwing capabilities to reducer

We're not sure how this would typically be used. It seems you would want to catch the errors and send them back into the system. Unless we provide some kind of reducer operator that can catch all errors to do something with them and then turn the reducer into a non-throwing one.

How to properly signal in an action that you have that there are cases that should not be public?

Yeah, this also seems like something Swift should implement, and there was even some chatter about it in the forums.

Otherwise the only thing I can think of is to follow the pattern you outlined. We do something similar to call out delegate actions that the parent is expected to handle.

[mackoj]

Thanks for taking the time to respond @mbrandonw. I will take the time to digest all of this informations and look around all of these branches.

It's great to see TCA progressing in all these ways I am eager to be able to use all these new features.

Thanks,

After a bit more digging proto-2 brach seems crazy.

• proto-2:
  • @ReducerBuilder aka ResultBuilder for Reducer
  • @Dependency new way to handle Environment
  • ReducerProtocol 🤯

I'm eager to learn more but at the same time I don't want to spoil myself.

[mackoj]

FWIW most issue described here are fixed with the latest beta 👍

This discussion can be considered obsolete.