Внедрения реактива в архитектуру iOS приложений

В статье про основы «реактива», мне кажется стоит отдельно упомянуть, что реактив имеет несколько важных контрактов, которые нельзя нарушать:

• поток заканчивается или с onComplete или с onError, но никак не с двумя одновременно
• onComplete или onError действительно прекращают поток и после их вызова нельзя эмитить другие элементы

Для кого-то это может показаться очевидным, однако, если создавать потоки самостоятельно или использовать Subject-ы, этот контракт легко можно сломать. А от сломанного контракта станут неправильно работать многие стандартные операторы типа concat, toList, last и много других.

Спасибо за статью.
Я пока подзаморозил написание своей по применению RxSwift, хоть она уже и была написана на половину, т.к. столкнулся с вопросами на которые у меня у самого нет «красивых» ответов.
Т.к. RxSwift, RAC — это реализации идеи функционального программирования — разумно использовать их мощь на полную.
Я же в итоге пришел к тому, что Rx отлично вписывается в биндинг с UI, но постоянно попадаются подводные камни.

Главная загвоздка в том, что идея реактивного программирования является — отсутствие состояния (в идеале). Отсюда идут настоятельные рекомендации подписываться на Observable только из UI (соответственно disposeBag должен быть только в ViewController'ах), т.к. подписки автоматически освободятся когда сменится экран. Т.е. та же ViewModel не должна иметь состояния.

Классическая схема MVVM если один контроллер создает другой
ParentViewController -> ParentViewModel -> ParentModel
ChildViewController -> ChildViewModel -> ChildModel

Причем ViewController знает о ViewModel, но не создает. А ParentViewModel — создает СhildViewModel
На все подписки по хорошему мы должны подписываться только в View
Ну и использовать переменные крайне не рекомендуется, только Observable только хардкоръ.

Но рассмотрим простую ситуацию.
Есть ViewController содержащий элементы логина + TableViewController (посредством контейнера).
Опять таки, по канонам ViewModel для TableViewController должен создавать ViewControllerModel.

ViewControllerViewModel когфигурируется из UI

class ViewControllerViewModel {
	func configure(login login: Observable<String>, password: Observable<String>, moduleId: Observable<String>, buttonParse: Observable<Void>) {
		...
		// внутри после всех проверок логина на пустоту и прочего в итоге мы получаем что то вроде этого

		let items: Observable<[DownloadTaskModel]> = parseState
		            .flatMapLatest{ (state) -> Observable<[DownloadTaskModel]> in
		                if case .Success(let data) = state {
		                    return Observable.just(data)
		                } else {
		                    return Observable.just([])
		                }
		            }.startWith([])
		        
		// и тут нам надо передать данные для TableViewModel, и мы не можем подписываться отсюда ни на что, т.к. мы внутри viewModel. Можно вытащить observable наружу, чтобы ViewController этой ViewModel "впустую" на него подписался, но это грабли.
		        tableViewModel.configure(items)

	}
}

У TableViewController же получается отрабатывает viewDidLoad раньше чем у его родителя ViewController, поэтому к моменту загрузки таблицы — у нас еще нет для нее данных, и приходится опять таки городить грабли

class TableViewControllerViewModel: NSObject, TableViewControllerViewModelProtocol {
    var session: NSURLSessionProtocol
    
    var disposeBag = DisposeBag()
    
    var dataSourceItems: Driver<[NumberSection]>! {
        didSet {
            completeConfigure.onNext()
        }
    }
    
    let completeConfigure: PublishSubject<Void> = PublishSubject()
    
    init(session: NSURLSessionProtocol = SessionFactory.sharedInstance.backgroundSession()) {
        self.session = session
        super.init()
    }
    
    func configure(items: Observable<[DownloadTaskModel]>) {
        
        dataSourceItems = items.asObservable().doOnNext{ [unowned self] _ in
            self.disposeBag = DisposeBag()
        }
            .map{[unowned self] models -> [NumberSection] in
                let protocols = models.map{ model -> DownloadableTaskViewModelProtocolThing in
                    let downloadDelegate = Downloader(session: self.session)
                    downloadDelegate.update.subscribe().addDisposableTo(self.disposeBag)
                    let cellViewModel = DownloadTaskViewModel(model: model, downloadDelegate: downloadDelegate)
                    downloadDelegate.updateStatusIfAlreadyDownloaded()
                    return DownloadableTaskViewModelProtocolThing(thing: cellViewModel)
                }

            }.asDriver(onErrorJustReturn: [])
    }
}

В TableViewController приходится подписываться на completeConfigure, и только после получения сигнала — конфигурировать dataSource для таблицы.

Есть альтернатива — делать dataSourceItems как переменную, изначально пустую и в configure — присваивать значение этой переменной.
Но я перечитал все issue где разработчик RxSwift отвечал на вопросы, и он черным по белому говорил — если вам приходится использовать переменную, либо вы что то делаете неправильно, либо у вас нет другого выхода. ViewModel не должна иметь состояния.
И несколько устаешь каждый раз думать первый это случай или второй.

Так же мне очень не нравится, что внутри ViewModel есть DisposeBag. А нужен он потому что нам надо подписываться на Observable update контроллера по закачке. Пробрасывать в TableViewController не получится, т.к. при каждом переконфигурировании данных для таблицы надо старую подписку сбрасывать.

Второй пример.
Есть DownloadController, его задача реагировать на нажатие кнопки у закачки соответственно,

В классическом варианте мы имеем что то вроде такого

class DownloadController {
...
func download() {
    switch model.status {
    case .Progress, .Wait:
        model.status = networkTaskManager.pause()
    case .Stopped, .Error:
        model.status = .Wait
        let task = session.downloadTaskWithURL(assetUrl())
        networkTaskManager.startPrepareTask(task)
    case .Paused:
        if let data = networkTaskManager.resumeData {
            model.status = .Wait
            let task = session.downloadTaskWithResumeData(data)
            networkTaskManager.startTask(task)
        } else {
            let task = session.downloadTaskWithURL(assetUrl())
            networkTaskManager.startTask(task)
        }
}
}

Model имеет биндинги, поэтому мы спокойно обновляем ее состояние, которое пробрасывается в ViewModel.

Когда я попробовал избавиться от состояния, то столкнулся с тем что код лишь усложнился. Как видно изменение статуса — не только результат операции — но и может меняться перед и во время операции, поэтому просто представить это как dataFlow уже не получается. Приходится делать постоянные сайд эффекты .doOnNext{ model.status =… } что снова таки по словам разработчика RxSwift — ugly hack, применение которого означает что вы что то делаете не так.
И в итоге получилось лишь усложнение.

Были еще моменты и не мало. Написал то что сразу в памяти всплыло.
Я скорее всего просто не умею готовить правильно FRP, признаю. Наверное это и есть steep learning curve. Но когда я понял, что я трачу 80% времени на то чтобы сделать «правильно по канонам FRP» вместо того чтобы писать полезный код, я отступил назад.
В итоге вернулся на шаг назад, — сделал самописный Bind, для простых задач связать Model->ViewModel->ViewController его хватает. Я конечно потерял много плюшек от RxSwift. Но признаться меня еще как то внезапно напрягло то, что это все таки не пара классов, это фреймворк, который пока мало кто использует. Как и саму парадигму FRP.
Т.к. в данный момент я лишь планирую выйти на рынок как фрилансер наверное было бы глупо уходить с головой в FRP, сомневаюсь что это нужно на небольших проектах, а как обьяснить клиенту, зачем я буду подключать ему целый фреймворк я пока не знаю.
Так что я пока взял паузу в наших отношениях с RxSwift.
При этом я ценю идею immutable заложенную в основу FRP, и данные сейчас стараюсь хранить в структурах, а не классах. Это тоже накладывает ограничения, и доставляет определенные неудобства (особенно весело с CoreData). Но их намного проще обойти и польза от них наглядная, причем все это бесплатно, без фреймворков.
Я не говорю, что FRP — плохо, но надо потратить не мало времени, чтобы умело пользоваться его арсеналом, при этом научиться обходить его ограничения.
Я пока остановился на модифицированном MVVM: (Router — ViewController — ViewModel — Model + Service Layer) При этом Model — структуры, что позволяет контролировать изменение данных. Ну и как я говорил — самописный биндинг.