Reaction — обработка результатов методов в Kotlin

[Stersh]

Зачем писать еще одну библиотеку, если в котлине уже есть стандартный Result у которого замечательный API? То что его нельзя возвращать даже плюс, так как все что вам нужно в таком случае делать — возвращать из функций чистые данные, а обрабатывать ошибки во ViewModel. Получается простой синхронный код без ненужных оберток.

[aTable7]

Не считаю код из вашего примера более простым.

Допустим, вы делаете запрос к серверу, который вернет либо данные, либо ошибку, что данные не найдены. Оба состояния — это бизнес логика, поэтому приходят с HTTP Result 200.
В моем случае, они обернуться в Reaction.Success и Reaction.Error. В вашем — придется делать дополнительный класс для передачи данных, либо кидать Exception на ошибку от сервера…

[yavfast]

В стандарте очень не хватает обработки пустого результата. Это и не null, и вроде как и не ошибка.
Вот из-за такого приходится велосипедить свою реализацию промисов.

[Yazon_dinAlt]

Как пример можно посмотреть на реализацию класса Result из корутин пакета.

[a_artikov]

А почему бы не использовать исключения для ошибок?

[aTable7]

На самом деле можно, но Throwable является их суперклассом, поэтому для использования ничего не поменяется.

[a_artikov]

Я имел ввиду, почему не делать, чтоб функция возвращала данные в случае успеха и кидала исключение при ошибке?

[aTable7]

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

[p2lem8dev]

По сути, единственное, что меняется, в случае использования reaction, result, вместо try-catch — это что ошибка будет трансформироваться в другой класс, что по сути, затрудняет понимание происходящего, а количество кода не уменьшает. Как использовалась куча условий для обработки ошибки, так и будет. Только в случае с try-catch, мы имеем более логичный результат — это будут либо чистые данные, либо ошибку, которую мы и так ожидаем.

Использование лишних библиотек для обертки результата приводит только повышению порога вхождения в проект и не приносит никаких плюсов.

[agent10]

Почитайте статью Елизарова — Kotlin and Exceptions.
Суть в том, что исключения не совсем тру. В вашем случае ошибка — это не исключение, а результат, пусть и отрицательный.

[goodvin1709]

Сейчас почти каждый «современный» Android(Kotlin) проект содержит это решение и у каждого название разное (Reaction, Result, ResultModel, ResultType etc.) но цель одна :)

[alaershov]

https://github.com/kittinunf/Result вот ещё хороший аналог.

[UltimateOrb]

Мне одному кажется идея с zip костылем? У вас есть Repository, который
возвращает Reaction [Success, Error]. Вы тупо мапите его в свой класс
вида State [Progress, Success, Error] что бы воткнуть такой же when где-то
в подписке на LiveData. В чем прикол?

[Dizze222]

А какой код у вас в DataSource?

[aTable7]

fun getData(): Reaction<String> = Reaction.on { dataSource.getData() }
, где dataSource.getData() просто возвращает строку.
Зайдите на https://github.com/taptappub/Reaction, там есть все описания и примеры