Sequential async void functions

[coenttb]

Dear community,

My goal is to run three async Void functions sequentially. In the snippet below, the intention is to clear the current documents, print the new documents, and call the completed action.

return .run { send in
                    await send(.print(.clearDocuments))
                    await send(.print(.print))
                    await send(.printCompleted)
                }

In the snipper however the print completed is fired before the print is done. I assume this is because the functions are not run sequentially and in the time print is running, printcomplete is already called.

I was wondering if there is a TCA idiomatic way to do this and would highly appreciate your input. Thank you in advance.

PS: it is my assumption that the provided code is enough information for an answer, but I'm more than happy to share more code if it is helpful to you.

PPS: I have also tried the following, with the same results:

return .concatenate(
                    Effect.init(value: .print(.clearDocuments)),
                    Effect.init(value: .print(.print)),
                    Effect.init(value: .printCompleted)
                )

[mbrandonw]

Hi @tenthijeboonkkamp, the await inside the Effect.run represents the async work to send the action on the main actor, not the lifecycle of the effect that is produced from sending the action.

You can even confirm this by annotating the closure with @MainActor and seeing that you no longer have to await at all:

return .run { @MainActor in send in
  send(.print(.clearDocuments))
  send(.print(.print))
  send(.printCompleted)
}

This shows that the 3 actions are sent one after another synchronously, regardless of what logic and effects are being executed for each action.

Is there a reason you have separated all of these steps into actions? Can it all be done in a single action and a single effect?

You might be interested in this section of our performance article which recommends against sharing logic in a reducer via actions, and instead using plain functions.

[coenttb]

Hi Brandon,

Thanks so much for the very quick reply.

I now understand that the 3 actions are sent one after another synchronously, but that the duration of the action is not taken into account.

The reason I have separated these is because I created a general PrintClient:

public struct PrintClient {
    public var printFolder: @Sendable (Folder, URL) async -> Void
}

I then create a general PrintFeature:

public struct PrintFeature:ReducerProtocol {
    @Dependency(\.printClient) var printClient
    
    public struct State:Equatable {
// note: Folder.Content is not Equatable
        public static func == (lhs: PrintFeature.State, rhs: PrintFeature.State) -> Bool {
            lhs.directory == rhs.directory
            && lhs.content.count == rhs.content.count
        }
        
        public let directory:URL
        public var printedDocuments:[URL]
        public var content: [Folder.Content]
        
        enum CodingKeys: String, CodingKey {
            case directory
        }
        
        var folder:Folder {
            return .init(name: "directory", content: content)
        }
        
        public init(directory: URL, printedDocuments:[URL], content: [Folder.Content]) {
            self.printedDocuments = printedDocuments
            self.directory = directory
            self.content = content
        }
    }
    
    public init(){}
    
    public enum Action:Equatable {
        case print
        case printComplete
        case clearDocuments
    }
    
    public func reduce(into state: inout State, action: Action) -> Effect<Action, Never> {
        switch action {
        case .print:
            return .task { [folder = state.folder, directory = state.directory] in

                await printClient.printFolder(folder, directory)
                return .printComplete
                }
        case .printComplete:
            do {
                state.printedDocuments =  try FileManager().contentsOfDirectory(at: state.directory, includingPropertiesForKeys: nil)
            } catch {
                Swift.print(error)
            }
            return .none
        case .clearDocuments:
            state.printedDocuments = []
            
            return .fireAndForget { [directory = state.directory] in
                let manager = FileManager()
                do {
                    let x = try manager.contentsOfDirectory(at: directory, includingPropertiesForKeys: nil)
                    try x.forEach { url in
                        try manager.removeItem(at: url)
                    }
                } catch {
                    print(error)
                }
            }
        }
    }
}

The reason for this is because this feature should be able to be used for various Apps that create documents. I'm a lawyer by trade and a hobby programmer. In my spare time I build form apps that generate (legal) letters in pdf. Having this function generalised allows me to use it for various apps.

[mbrandonw]

It seems to me that the lifecycle of "clear previously printed documents, print documents, get urls of printed documents" is more appropriate to be represented in the PrintClient dependency.

So, you could beef up the PrintClient to also have endpoints for clearing documents and getting previously printed documents:

struct PrintClient {
  var printFolder: (Folder, URL) async -> Void
  var printedDocuments: (URL) async throws -> [URL]
  var clearDocuments: (URL) throws -> Void
}

(Side note: It seems that printFolder and printedDocuments could even be combined into one step. Why not when you print a folder you just get back the URLs of all the documents?)

Then you could have a function defined on PrintClient that represents the full lifecycle of clearing, printing and getting URLs:

extension PrintClient {
  func print(
    folder: Folder, 
    directory: URL
  ) async throws -> [URL] {
    try self.printClient.clearDocuments()
    await self.printClient.printFolder(folder, directory)
    return try await self.printClient.printedDocuments(diretory)
  }
}

And then in your reducer you would return an effect that calls the above print method with the full lifecycle baked in and would feed its response back into the system with some kind of printResponse action (you can even use TaskResult if you want to react to any errors):

case .printButtonTapped:
  return .run { send in 
    await send(
      .printResponse(
        TaskResult {
          try await self.printClient.print(folder, directory)
        }
      )
    )
  }

That's the basic idea at least.

I think in the long run it will be a lot more powerful to represent this "print feature" in terms of composing various parts of the dependencies together rather than modeling it as its own reducer.

[coenttb]

That's definitely a great improvement and it taught me something fundamental on how to design these features as standalone Clients instead off having to also implement it in a feature.

Thank you very much, I got it working.