v
ТЕА
пытался разобраться, сломал мозга
Size: a a a
2020 July 17
v
ну и это всё же архитектурный паттерн, а хотелось бы какое-то более конкретное решение
AD
ну и это всё же архитектурный паттерн, а хотелось бы какое-то более конкретное решение
более чем конкретное получается
v
более чем конкретное получается
дай что нормальное почитать про него, если есть.
А то я слабо понял то, что читал я.
А то я слабо понял то, что читал я.
v
этож там где редьюсеры и огромная колбаса из стейта?)
AD
этож там где редьюсеры и огромная колбаса из стейта?)
EP
Давно интересует одна тема, никак не могу найти полностью удовлетворяющее меня решение.
Допустим, дело обстоит вот так:
у меня есть юзкейс (или метод), скажем, "BackupUserData". Он берёт из базы юзеров и бекапит их по одному. Вот у него есть коллбек onBackupResult, в него возвращается лист юзеров и репорт об успешности / неуспешности операции. Проблема же заключается в том, что если я хочу получать какое-то промежуточное состояние операции в слое представления и / или передавать туда данные по мере необходимости, приходится писать какую-то фигню (в архитектурном смысле).
Я ищу способ оставить целостность логики (одна очерченная бизнес-логикой функция - один юз кейс) и при этом иметь возможность взаимодействовать с этим флоу по мере его исполнения.
Моё ублюдочное решение:
Я передаю лямбды в параметрах и возвращаю какие-то лютые кортежи с лямбдами в коллбек (особенно дико это выглядит если принимать во внимание, что у меня ырыкс, который не должен торчать снаружи либы). Выглядит это нечитаемо и я ощущаю, что можно сделать лучше, но не знаю, каким образом. Был вариант создавать по интерфейсу на каждый входной / выходной параметр. Делать так или не делать? В общем, жду ваши варианты, леди и джентльмены)
Допустим, дело обстоит вот так:
у меня есть юзкейс (или метод), скажем, "BackupUserData". Он берёт из базы юзеров и бекапит их по одному. Вот у него есть коллбек onBackupResult, в него возвращается лист юзеров и репорт об успешности / неуспешности операции. Проблема же заключается в том, что если я хочу получать какое-то промежуточное состояние операции в слое представления и / или передавать туда данные по мере необходимости, приходится писать какую-то фигню (в архитектурном смысле).
Я ищу способ оставить целостность логики (одна очерченная бизнес-логикой функция - один юз кейс) и при этом иметь возможность взаимодействовать с этим флоу по мере его исполнения.
Моё ублюдочное решение:
Я передаю лямбды в параметрах и возвращаю какие-то лютые кортежи с лямбдами в коллбек (особенно дико это выглядит если принимать во внимание, что у меня ырыкс, который не должен торчать снаружи либы). Выглядит это нечитаемо и я ощущаю, что можно сделать лучше, но не знаю, каким образом. Был вариант создавать по интерфейсу на каждый входной / выходной параметр. Делать так или не делать? В общем, жду ваши варианты, леди и джентльмены)
А вы всегда передаете данные сверху вниз. Низ не может запросить данные у верха по другому каналу?
v
Eugene P.
А вы всегда передаете данные сверху вниз. Низ не может запросить данные у верха по другому каналу?
ну, если потоку данных понадобится что-то у юзера спросить, у я дёргаю лямбды из параметров 🤭
v
Вроде, видел эту статью, но многабукаф. Но сейчас почитаю, спасибо)
EP
Теоретически можно иметь шину событий, послать туда запрос, а потом ждать ответ вместо лямбд. У Badoo была статья на хабре с довольно красивым решением
v
Eugene P.
Теоретически можно иметь шину событий, послать туда запрос, а потом ждать ответ вместо лямбд. У Badoo была статья на хабре с довольно красивым решением
ну, если очень грубо говорить, то это и есть шина событий ведь
AD
Вроде, видел эту статью, но многабукаф. Но сейчас почитаю, спасибо)
EP
ну, если очень грубо говорить, то это и есть шина событий ведь
ну вы избавляетесь от миллиона параметров
v
Ого. Спасибо)
AD
Ого. Спасибо)
чо спасибо-то
иди это еще прикрути к экзекьюторам)
иди это еще прикрути к экзекьюторам)
v
ну буду пробовать)
EP
v
Eugene P.
спасибо, почитаю
v
Eugene P.
о, я читал первые 2 части.