ReactFX: exploration of reactive programming for JavaFX (was: [announce] InhiBeans: mitigate redundant recalculations)

[Tomas Mikula]

Hi all,

InhiBeans evolved into ReactFX [1], which now includes reactive-style event
stream compositions and more.

Best regards,
Tomas

[1] https://github.com/TomasMikula/ReactFX


On Mon, Dec 16, 2013 at 7:31 PM, John Smith <John_Smith at symantec.com> wrote:

> Perhaps reactive programming is different from the problem Tomas is
> solving, but I think a research project which combined some of the
> principles of functional reactive programming (
> http://lampwww.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf) with
> JavaFX properties using Java 8 lambdas and streams would be quite
> interesting and perhaps very useful.
>
> John
>
> -----Original Message-----
> From: openjfx-dev-bounces at openjdk.java.net [mailto:
> openjfx-dev-bounces at openjdk.java.net] On Behalf Of Tomas Mikula
> Sent: Monday, December 16, 2013 9:19 AM
> To: Richard Bair
> Cc: openjfx-dev at openjdk.java.net
> Subject: Re: [announce] InhiBeans: mitigate redundant recalculations
>
> As a matter of fact, I have. Only to the extent of the "Principles of
> Reactive Programming" [1] course that is currently in progress on Coursera.
> From what I have seen so far, it's all about asynchronous composition (with
> emphasis on both "asynchronous" and "composition").
> I didn't see it addressing this specific problem of multiple redundant
> updates, but I might be wrong. The truth is, this problem doesn't even
> exist if you don't have any eager observers (i.e. when you don't ever
> attach any ChangeListeners, and InvalidationListeners only propagate
> invalidation and never require the value to be recomputed). The problem is,
> although you can design your component without any eager evaluation (JavaFX
> bindings are already composed this way), you then bind a
> Label.textProperty() to the end of a binding chain and it all becomes eager.
>
> Regards,
> Tomas
>
> [1] https://www.coursera.org/course/reactive
>
> On Mon, Dec 16, 2013 at 5:30 PM, Richard Bair <richard.bair at oracle.com>
> wrote:
> > Have you looked at https://github.com/Netflix/RxJava by chance? I've
> been dying to see somebody do an RxJava in JavaFX ever since devoxx and it
> looks like you may have inadvertently started down that path :-).
> >
> > Richard
> >
> > On Dec 16, 2013, at 8:09 AM, Tomas Mikula <tomas.mikula at gmail.com>
> wrote:
> >
> >> On Mon, Dec 16, 2013 at 1:47 AM, Tomas Mikula <tomas.mikula at gmail.com>
> wrote:
> >>> On Mon, Dec 16, 2013 at 1:07 AM, Scott Palmer <swpalmer at gmail.com>
> wrote:
> >>>> Interesting, no worse than John's pattern though.
> >>>> I thought of using a try/finally to make sure release was called
> >>>> and that naturally lead to thinking of try-with-resources, where
> >>>> the "resource" in this case is a binding of some sort (or a wrapper
> >>>> around a binding) that is invalidated on close() if needed.
> >>>
> >>> That is an interesting idea. I didn't intend blockWhile() to be safe
> >>> with respect to exceptions, but merely
> >>>
> >>> void blockWhile(Runnable r) {
> >>>    block();
> >>>    r.run();
> >>>    release();
> >>> }
> >>>
> >>> Enhancement you are suggesting could be fleshed out as block()
> >>> returning an AutoCloseable and the usage would be
> >>>
> >>> try(AutoCloseable a = relaxedArea.block()) {
> >>>    obj.setWidth(w);
> >>>    obj.setHeight(h);
> >>> }
> >>
> >> OK, done. I implemented both:
> >> 1. added the blockWhile() method;
> >> 2. made bindings AutoCloseable, and block() returns `this`.
> >>
> >> Tomas
> >
>