IdentifiedClosure

[o-nnerb]

It would be very interesting if it were possible to use closures to be executed when a certain condition within the reducer is satisfied.

I understand that there is communication between reducers, and this feature may not fit perfectly with the purpose of TCA, but it would allow for further exploration of integration with code independent of TCA rules.

The idea is to be able to use a closure as part of the initialization of a reducer's State, which would be both Equatable and Hashable.

For example:

struct SomeReducer: ReducerProtocol {

    struct State {

        let onViewClose: () -> Void
    }

    // code
}

Since closures in Swift are primitive types, it is not possible to implement conformance to Equatable and Hashable, and the above code would not compile. This is related to #2193

However, if we consider how a closure is created in Swift, we can understand that it has a reference to code located elsewhere and continues to exist until its reference is destroyed in both the creator and receiver.

In this way, it is possible to implement something like this:

public struct IdentifiedClosure<Input, Output> {

    private let closure: (Input) -> Output
    private let seed: Seed

    fileprivate init(_ closure: @escaping (Input) -> Output) {
        self.closure = closure
        self.seed = .init()
    }

    public func callAsFunction(_ input: Input) -> Output {
        closure(input)
    }
}

This can be initialized using the method:

extension IdentifiedClosure {

    public static func closure(_ closure: @escaping (Input) -> Output) -> Self {
        .init(closure)
    }
}

Then, the seed would be used to implement Equatable and Hashable.

[natemann]

I have used closures in TCA Multiple times to communicate to non-TCA parent views. To do this, I have just used the closure as an Environment variable / ReducerProtocol variable. Neither Environment or ReducerProtocol typically has to conform to Equatable.

[acosmicflamingo]

This is actually what UIButton.Configuration does for handling updating the color states (although it doesn't make it Identifiable):

public struct UIConfigurationColorTransformer {

    public let transform: (UIColor) -> UIColor

    public init(_ transform: @escaping (UIColor) -> UIColor)

    public func callAsFunction(_ input: UIColor) -> UIColor

    /// A color transformer that returns a grayscale version of the color.
    public static let grayscale: UIConfigurationColorTransformer

    /// A color transformer that either passes the original color through, or replaces it with the system accent color.
    /// - When the system accent color is set to Multicolor: Returns the original color.
    /// - When the system accent color is configured to any other color:  Returns that color.
    /// - On platforms without a system accent color: Returns the original color.
    public static let preferredTint: UIConfigurationColorTransformer

    /// A color transformer that gives the color a monochrome tint. Use this to deemphasize the tinted item.
    /// It remains monochrome regardless of the system accent color (if the platform has one).
    public static let monochromeTint: UIConfigurationColorTransformer
}

I don't see anything wrong with what you are implementing. I guess it's just one of those "Try it and see what happens" kind of things ;)

[o-nnerb]

I apologize for the confusion. The implementation I mentioned is actually related to this discussion #2193, where I require conformance to the Equatable protocol.

I've been using this solution for a while now and wanted to include it as part of the TCA source code. That's why I made a mistake by stating that the code doesn't compile using a closure () -> Void when, in fact, it does compile.

Thank you for the feedback ❤️