react-flux: A binding to React based on the Flux application architecture for GHCJS

[ bsd3, library, web ] [ Propose Tags ]

Flags

Automatic Flags
NameDescriptionDefault
example

Build the TODO example application

Disabled
test-client

Build the test client application

Disabled

Use -f <flag> to enable a flag, or -f -<flag> to disable that flag. More info

Downloads

Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees

Candidates

  • No Candidates
Versions [RSS] 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.0.5, 1.0.6, 1.0.7, 1.1.0, 1.1.1, 1.2.0, 1.2.1, 1.2.2, 1.2.3
Change log ChangeLog.md
Dependencies aeson (>=0.8), base (>=4.7 && <5), deepseq, ghcjs-base, mtl (>=2.1), react-flux, text (>=1.2) [details]
License BSD-3-Clause
Author John Lenz <wuzzeb@gmail.com>
Maintainer John Lenz <wuzzeb@gmail.com>
Category Web
Home page https://bitbucket.org/wuzzeb/react-flux
Source repo head: hg clone https://bitbucket.org/wuzzeb/react-flux
Uploaded by JohnLenz at 2015-08-22T16:53:18Z
Distributions
Reverse Dependencies 1 direct, 1 indirect [details]
Executables test-client, todo
Downloads 10326 total (61 in the last 30 days)
Rating 2.5 (votes: 5) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs available [build log]
Last success reported on 2015-10-18 [all 2 reports]

Readme for react-flux-0.9.1

[back to package description]

A GHCJS binding to React based on the Flux design. The flux design pushes state and complicated logic out of the view, allowing the rendering functions and event handlers to be pure Haskell functions. When combined with React's composable components and the one-way flow of data, React, Flux, and GHCJS work very well together.

Docs

The haddocks contain the documentation.

Build

This package requires GHC 7.10 (I am using GHC 7.10.2) and the improved-base branch of ghcjs. I followed the instructions in the ghcjs wiki to install the improved-base branch. Once ghcjs is installed, I use the following to build react-flux:

echo "compiler: ghcjs" > cabal.config
cabal configure
cabal build

TODO Example Application

The source contains an example TODO application.

cabal configure -fexample
cabal build
cd example
make
firefox todo.html

If you don't have closure installed, you can open example/todo-dev.html.

Test Suite

To run the test suite, first you must build both the example application and the test-client. (The test-client is a react-flux application which contains everything not contained in the todo example.)

echo "compiler: ghcjs" > cabal.config
cabal configure -fexample -ftest-client
cabal build
cd example
make

The above builds the TODO application, compresses it with closure, and builds the test client. Next, install selenium-server-standalone (also from npm). Then, build the hspec-webdriver test suite using GHC (not GHCJS). I use stack for this, although you can use cabal too if you like.

cd test/spec
stack build

Finally, start selenium-server-standalone and execute the test suite. It must be started from the test/spec directory, otherwise it does not find the correct javascript files.

.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/react-flux-spec/react-flux-spec

Other Projects

It differes significantly from the other two react bindings, react-haskell and ghcjs-react. In particular, the major difference is how events are handled. In the Flux design, the state is moved out out of the view and then handlers produce actions which transform the state. Thus there is a one-way flow of data from the store into the view. In contrast, react-haskell and ghcjs-react both have event signals propagaing up the react component tree, transforming state at each node. In particular, react-haskell with its InSig and OutSig have the signals propagate up the tree and optionally transform state at each node and change the type of the signal.