Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Functional Reactive UI Thing for Declarative UI Behavior

branch: master

Fetching latest commit…

Octocat-spinner-32-eaf2f5

Cannot retrieve the latest commit at this time

Octocat-spinner-32 core
Octocat-spinner-32 demos
Octocat-spinner-32 plugin
Octocat-spinner-32 project
Octocat-spinner-32 readme
Octocat-spinner-32 sbt
Octocat-spinner-32 .gitignore
Octocat-spinner-32 README.md
README.md

Declarative UI Behavior with Fruit

22 Oct 2011

Build Status

Fruit is a framework for building UI workflows declaratively using continuations and functional reactive programming.

To run the demo, first build the Scala compiler plugin:

> sbt/sbt "fruit-plugin/publish-local"

Then run the demo:

> sbt/sbt "fruit-demos/run-main fruit.FruitDemo"

Defining behavior in the conventional way via observers leads to some pretty ugly code. After reading Deprecating the Observer Pattern, a paper by Martin Odersky, Tiark Rompf, and Ingo Maier, I decided to put together a little framework for writing UI behavior in a declarative style, using delimited continuations and functional reactive programming take the mess of wiring up ActionListeners and sweep it under the rug. The outcome of this effort is Fruit, the Functional Reactive UI Thing.

Consider the following UI:

Fruit screenshot 1

This panel includes a combo box and a label. Changes to the combo box selection are reflected in the label:

Fruit screenshot 2

Fruit screenshot 3

Conventionally this would require adding to the combo box an ActionListener which would encapsulate the (relatively simple) logic of what to do with updates to the combo box selection; in this case, updating the text of the label. With Fruit, it is as simple as a one-line declaration:

label1.setText(signal(combo1))

This treats the combo box as a signal, and the text of the label is set to the time-varying value of the combo box signal. This can be used to build up more complex UI workflows:

label1.setText(signal(combo1))
label2.setText(signal(combo2))
label3.setText(signal(combo1) + " is " + signal(combo2))
label4.setText(signal(combo1) + " ain't " + signal(combo2))

Here we have four labels which are updated based on the selection of the first combo box, the selection of the second combo box, or both. It keeps the UI workflow together, and is much easier to reason about than with observer implementations scattered about.

Fruit screenshot 4

Fruit screenshot 5

Fruit screenshot 6

Fruit screenshot 7

Fruit screenshot 8

Something went wrong with that request. Please try again.