Темная сторона однонаправленных архитектур Swift

Введение

В этой статье речь пойдет о главной проблеме всех однонаправленных архитектур Swift. Собственно говоря, это не проблема однонаправленных архитектур как таковых. Скорее, это проблема моделирования действий или событий как значений. Я ее называю “пинг-понг-проблемой”. Все дело в “скачках” между разными местами кода, которые приходится преодолевать, чтобы получить целостное представление обо всем потоке. Рассмотрим для начала простой пример.

func handle(event: Event) {

    switch event {

    case .onAppear:

        state = .loading

        return .task {

            let numbers = try await apiClient.numbers()

            await send(.numbersDownloaded(numbers))

        }

    

    case .numbersDownloaded(let values):

        state = .loaded(values)

        return .none

    }

}

Этот код довольно легко читается, но есть еще более простая его версия:

func onAppear() {

    Task {

        state = .loading

        let numbers = try await apiClient.numbers()

        state = .loaded(numbers)

    }

}

В этой версии не только меньше кода. В ней более связный и понятный код.

При моделировании события как значения теряется возможность читать весь код сверху вниз как целостную часть поведения. Приходится перебирать событие за событием, чтобы сформировать целостное понимание конкретного потока: некое входное событие вызывает какое-то событие обратной связи, которое вызывает другое событие обратной связи и т. д. Между этими событиями может быть множество различных связей, что усложняет понимание кода.

Но, как правило, применение любой архитектуры к любому тривиальному примеру выглядит как чрезмерный инжиниринг.

Представьте, что в предыдущем коде используется что-то вроде архитектуры CLEAN.

func onAppear() {

    Task {

        state = .loading

        let numbers = try await usecase.numbers()

        state = .loaded(values)

    }

}



class UseCase {

    let repository: RepositoryContract



    func numbers() async throws -> [Int] {

        repository.numbers()

    }

}



protocol RepositoryContract {

    func numbers() async throws -> [Int]

}



class Repository: RepositoryContract {

    let apiClient: APIClient



    func numbers() async throws -> [Int] {

        apiClient.numbers()

    }

}

В обоих случаях введена ненужная косвенность. Чтобы понять такой код, приходится заглядывать в разные места.

Даже ради слоев и абстракций, позволяющих управлять сложностью, обеспечивать гибкость и облегчать тестирование, не стоит забывать об утрате важного принципа программного обеспечения — “локальности поведения” (также называемого “локальным обоснованием”). Как и во всем, здесь не обойтись без компромисса.

Моделирование событий как значений обладает большими преимуществами, например дает возможность полностью отследить изменения состояния и вызвавшие их события. Но это сопряжено с риском для удобочитаемости. Напомню, что код всегда должен быть оптимизирован для удобства прочтения.

Теперь рассмотрим более сложный пример, вдохновленный рабочим процессом фреймворка Mobius от Spotify.

Пинг-понг-проблема на практике

Используя однонаправленную архитектуру, реализуем простой экран входа в систему со следующими требованиями:

• Пользователь может ввести e-mail и пароль для входа в систему.

• В случае отсутствия интернета пользователь не сможет войти в систему.

• Электронная почта сначала проходит локальную валидацию, а затем удаленную.

• Пароль не проходит валидацию.

• Перед попыткой входа в систему пользователь должен пройти процедуру подтверждения.

У нас будет три разных реализации, но сначала разберемся с двумя общими частями: состоянием и эффектами.

struct State: Equatable {
    var online: Bool = true
    var email: Email = .init()
    var password: String = ""
    var loggingIn: Bool = false

    var canLogin: Bool {
        online && email.valid && password.count > 8
    }

    struct Email: Equatable {
        var rawValue: String = ""
        var valid: Bool = false
        var currentValidation: Validation? = nil

        enum Validation {
            case local
            case remote
        }
    }
}

enum Effects {
    static func login() async throws -> String {
        "dummy token"
    }

    static func localEmailValidation(_ email: String) -> Bool {
        email.contains("@")
    }

    static func remoteEmailValidation(_ email: String) async -> Bool {
        return Bool.random()
    }

    static func showConfirmation(text: String, yes: () async -> Void, no: () async -> Void) async {}
    static func onlineStream() -> AsyncStream<Bool> {}
}

Реализация 1: полная однонаправленная архитектура

class ViewReducer: Reducer {

    enum Input {

        case onAppear

        case emailInputChanged(String)

        case passwordInputChanged(String)

        case loginButtonClicked

    }



    enum Feedback {

        case internetStateChanged(online: Bool)

        case loginSuccessful(token: String)

        case loginFailed

        case emailLocalValidation(valid: Bool)

        case emailRemoteValidation(valid: Bool)

        case loginAlertConfirmation(confirm: Bool)

    }



    enum Output {

        case showErrorToast

        case loginFinished(_ token: String)

    }



    func reduce(message: Message<Input, Feedback>, into state: inout State) -> Effect<Feedback, Output> {

        switch message {

        // ПОМЕТКА: - Входные события

        case .input(.onAppear):

            return .run { send in

                for await online in Effects.onlineStream() {

                    await send(.internetStateChanged(online: online))  

                }

            }



        case .input(.emailInputChanged(let value)):

            state.email.rawValue = value

            state.email.valid = false

            state.email.currentValidation = .local



            let email = state.email.rawValue

            return .run { send in

                let valid = Effects.localEmailValidation(email)

                await send(.emailLocalValidation(valid: valid))

            }



        case .input(.passwordInputChanged(let value)):

            state.password = value

            return .none



        case .input(.loginButtonClicked):

            guard state.canLogin else {

                fatalError("Shouldn't be here")

            }



            return .run { send in

                await Effects.showConfirmation(text: "Are you sure?") {

                    await send(.loginAlertConfirmation(confirm: true))

                } no: {

                    await send(.loginAlertConfirmation(confirm: false))

                }

            }



        // ПОМЕТКА: - События обратной связи

        case .feedback(.emailLocalValidation(valid: let valid)):

            guard valid else {

                state.email.currentValidation = nil

                return .none

            }

            state.email.currentValidation = .remote

            let email = state.email.rawValue

            return .run { send in

                let valid = await Effects.remoteEmailValidation(email)

                await send(.emailRemoteValidation(valid: valid))

            }



        case .feedback(.emailRemoteValidation(valid: let valid)):

            state.email.valid = valid

            state.email.currentValidation = nil

            return .none



        case .feedback(.loginAlertConfirmation(true)):

            state.loggingIn = true

            return .run { send in

                do {

                    let token = try await Effects.login()

                    await send(.loginSuccessful(token: token))

                } catch {

                    await send(.loginFailed)

                }

            }



        case .feedback(.loginAlertConfirmation(false)):

            return .none



        case .feedback(.loginSuccessful(token: let token)):

            state.loggingIn = false

            return .output(.loginFinished(token))



        case .feedback(.loginFailed):

            state.loggingIn = false

            return .output(.showErrorToast)



        case .feedback(.internetStateChanged(let online)):

            state.online = online

            return .none

        }

    }

}

Чтобы разобраться со всем процессом входа, нужно понять, как обрабатывается множество разнообразных событий:

• входное событие emailInputChanged  -> событие обратной связи emailLocalValidation -> событие обратной связи emailRemoteValidation;

• входное событие loginButtonClicked -> событие обратной связи loginAlertConfirmation ->событие обратной связи loginSuccessful.

Чтобы понять, что происходит, когда пользователь вводит e-mail и нажимается кнопка входа (login button), приходится посмотреть довольно много событий и переходов между ними. Даже если объединить связанные события в операторе switch, чтобы минимизировать скачкообразность переходов между ними, этот код все равно будет слишком громоздким с резкими скачками и косвенными указаниями.

События обратной связи — вот что производит все эти “пинг-понг-скачки” туда-сюда. Что произойдет, если их убрать? Посмотрим.

Реализация 2: удаление событий обратной связи

Напишем ViewModel с нуля. На этот раз будем моделировать только входные и выходные события как значения.

class ViewModel {

    enum Input {

        case onAppear

        case emailInputChanged(String)

        case passwordInputChanged(String)

        case loginButtonClicked

    }



    enum Output {

        case showErrorToast

        case loginFinished(_ token: String)

    }



    private(set) var state: State

    let stream: AsyncStream<Output>

    private let continuation: AsyncStream<Output>.Continuation



    init() {

        let (stream, continuation) = AsyncStream.makeStream(of: Output.self)

        self.stream = stream

        self.continuation = continuation

        self.state = .init()

    }



    func send(_ input: Input) {

        switch input {

        case .onAppear:

            Task {

                for await online in Effects.onlineStream() {

                    self.state.online = online

                }

            }



        case .emailInputChanged(let value):

            state.email.rawValue = value

            state.email.valid = false

            state.email.currentValidation = .local

            let valid = Effects.localEmailValidation(value)



            guard valid else {

                state.email.currentValidation = nil

                return

            }



            state.email.currentValidation = .remote

            Task {

                let valid = await Effects.remoteEmailValidation(value)

                state.email.valid = valid

                state.email.currentValidation = nil

            }



        case .passwordInputChanged(let value):

            state.password = value



        case .loginButtonClicked:

            guard state.canLogin else {

                fatalError("Shouldn't be here")

            }



            Task {

                await Effects.showConfirmation(text: "Are you sure?") {

                    state.loggingIn = true

                    defer {

                        state.loggingIn = false

                    }

                    do {

                        let token = try await Effects.login()

                        continuation.yield(.loginFinished(token))

                    } catch {

                        continuation.yield(.showErrorToast)

                    }

                } no: {

                    // Ничего

                }

            }

        }

    }

}

Удаление событий обратной связи значительно упростило код. Теперь снова можно читать сверху вниз, и мы видим, что связанные части находятся вместе. Этот код получился более целостным, чем раньше.

Реализация 3: удаление событий как значений

При отсутствии необходимости вести лог и отслеживать входные события, лучше избежать этого массива переходов, используя вместо них простые функции.

class ViewModel {

    enum Output {

        case showErrorToast

        case loginFinished(_ token: String)

    }



    private(set) var state: State

    let stream: AsyncStream<Output>

    private let continuation: AsyncStream<Output>.Continuation



    init() {

        let (stream, continuation) = AsyncStream.makeStream(of: Output.self)

        self.stream = stream

        self.continuation = continuation

        self.state = .init()

    }



    func onAppear() {

        Task {

            for await online in Effects.onlineStream() {

                self.state.online = online

            }

        }

    }



    func emailInputChanged(value: String) {

        state.email.rawValue = value

        state.email.valid = false

        state.email.currentValidation = .local



        let valid = Effects.localEmailValidation(value)



        guard valid else {

            state.email.currentValidation = nil

            return

        }



        state.email.currentValidation = .remote

        Task {

            let valid = await Effects.remoteEmailValidation(value)

            state.email.valid = valid

            state.email.currentValidation = nil

        }

    }



    func passwordInputChanged(value: String) {

        state.password = value

    }



    func loginButtonClicked() {

        guard state.canLogin else {

            fatalError("Shouldn't be here")

        }



        Task {

            await Effects.showConfirmation(text: "Are you sure?") {

                state.loggingIn = true

                defer {

                    state.loggingIn = false

                }

                do {

                    let token = try await Effects.login()

                    continuation.yield(.loginFinished(token))

                } catch {

                    continuation.yield(.showErrorToast)

                }

            } no: {

                // Ничего

            }

        }

    }

}

На мой взгляд, эта последняя версия кода читается гораздо лучше, чем любая другая.

Заключение

Как видите, события обратной связи и скачкообразные переходы между ними могут повлиять на удобочитаемость кода, затрудняя его понимание и получение целостного представления о функциональности.

Примите во внимание, что представленный пример демонстрирует максимально проблематичный случай. Можно привести и другие примеры, в которых более ограниченный способ управления состоянием, позволяющий ему изменяться только через события, приводит к гораздо более понятному коду.

Мне было важно показать, чем порой оборачивается решение о применении однонаправленной архитектуры. И дело не только в пинг-понг-проблеме, но и в рассогласовании со SwiftUI, где связывания и другие обертки свойств не вписываются естественным образом и требуют дополнительного кодового шаблона.

Мало того, рассогласование происходит и с эргономикой статического анализа и навигации Xcode. Мы теряем возможность перейти непосредственно к определению функции (переходя к case в enum, вынуждены искать этот case в операторе switch, чтобы увидеть реализацию конкретного события) или использовать удобные функции вроде “иерархии вызовов” в Xcode.

На мой взгляд, более безопасный подход для большинства разработчиков — опираться на минималистическую ViewModel (или другой вид тонкого слоя контроллера/координатора) и переносить как можно больше логики в соответственно смоделированный домен. 

Правда, такая “свободная архитектура” может очень легко выйти из-под контроля, если не соблюдать осторожность, в то время как однонаправленные архитектуры обычно отличаются более жесткими ограничениями и строго предусматривают, где и как обрабатываются состояния и эффекты. У всего есть свои плюсы и минусы. Делайте разумный выбор.