Is this a good way to do it in JavaFX?

[Paul Houle]

This is what I am doing inside a JavaFX application:

@Override
public void run() {
    Flux<String> ultimateSource = Flux.fromStream(br.lines());
    Subscriber<Runnable> guiSystem = new ConsumerSubscriber<Runnable>(
            x -> runLater(x),
            x -> whenDone.accept(x),
            () -> whenDone.accept(null)
    );

    ultimateSource.map(this::stringsToUpdates).subscribeWith(guiSystem);
}

this is a minimum interesting example,  I think,  because I am taking a BufferedReader and putting it through the (very stateful) stringsToUpdates() function

which returns Runnables which get runLater() in the "JavaFX Application Thread".  The ConsumerSubscriber also routes completion and errors to a 

Consumer<Throwable> which ties up any loose ends at the end in the GUI and otherwise,  I want these running in some thread that is not the "Java FX 

Application Thread" but otherwise I am not that picky.

It seems to work but I want to check that it is making sense.

Some more things:

(1) How do I go the whole way and pipe GUI events in context through the framework

(2) So long as GUI updates commute,  which they will most of the time,  the system will operate predictably,  but I could imagine situations where they don't.  Non-commutative operators such as .clear() will be sometimes necessary however,  and I am wondering how to set up a "barrier" of some kind to manage this.

[Stephane Maldini]

Note : You can now ask these questions directly on the issue tracker (reactor-core) to get more immediate attention from others contributors as well. 

AS I hinted in the other mail, any Thread switch should be done inside a specific contract if possible, Scheduler. I would then simply use doOnComplete and doOnError to map the two whenDone notifications. 

Effectively you're not doing it wrong in that case because ConsumerSubscriber (now named LambdaSubscriber) is for unbounded consumer interface subscribe(). It could be seen as a Sink to Platform. However if you want to continue composing on these events, using the thread-switch operators subscribeOn (switch thread on the Subscription side, the left) and publishOn (switch thread on the Subscriber side, the right).

--
You received this message because you are subscribed to the Google Groups "reactor-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reactor-framew...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Stephane Maldini | Reactor Project Lead, Spring Engineering | London | Pivotal

W: pivotal.io | T: @smaldini