Огромное спасибо за статью! Замечательная подача тех. материала и литературный дар.
Если есть возможность, пожалуйста, продолжайте!
Спасибо за статью. Было бы интересно почитать о том как отрефакторить существующий код под новый реактивный манер. Например вот интересно различные подходы конвертации итеративного метода (возвращающего список объектов) так чтобы он возвращал Flux. Должен ли этот новый метод создавать поток чтобы сабмитать новые объекты (hot stream), или же этот метод должен только оборачивать список объектов в Flux (и вызывать метод complete)?
Не до конца понял вопрос, но попробую ответить. Какого-то универсального рецепта нет, все упирается в данные. Если метод возвращает весь необходимый список объектов единовременно (не потоком) — вероятно это не Flux, а Mono. Hot Stream это скорее про какие-нибудь Event Listener на UI или системные ивенты, вебсокеты. Что-то, вызов чего мы не контролируем.

Вот конкретный пример. Есть некий итеративный метод который возвращает список найденных блютус устройств: List<DiscoveredDevice> getDiscoveredDevices(). Каждый вызов этого метода может возвратить разные устройства. Необходимо отрефакторить данный метод так чтобы он стал реактивным, а именно, чтоб он возвращал нескончаемый поток, так чтобы клиенты могли бы подписаться на этот поток, и соответственно, получать новые устройства. Первое что приходит в голову это — Flux<DiscoveredDevice> getDiscoveredDevicesStream(), где внутри этого метода создается поток (thread), и по мере обнаружения новых устройств, вызывался бы emitter.next(...). Однако кажется мне что создание потока не совсем верное решение, ибо в reactor'е есть столько различный способов работы с потоками, что может быть это можно как-то решить с помощью reactor'а? Кроме того, может быть лучше работу с потоком возложить на клиента этого метода? Спасибо.

Если хотите бесконечный поток данных (push based), то я не вижу другого выхода. Кто-то ведь должен вызывать emitter.next у FluxSink. С точки зрения реактора можно воспользоваться шедулером.

Вариант проще — pull based подход через fluxSink.onRequest. Тут и нить выполнения можно изменить через subscribeOn. Правда, в этом случае сложно организовать «бесконечную» работу.

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