But seriously, Fastflux just continues further in the logical direction established by Redux (and arguably React itself) -- a more reactive approach to software development.
Fastflux does this by using an implementation of the Observable FRP primitive as a superclass for stores and actions.
As someone who makes heavy use of redux-rx[1], this looks fantastic. While using Redux, one of the greatest productivity gains I encountered was moving more parts of my application to frp. In particular, I've found that reflecting portions of my apps state in the URL was challenging with vanilla redux + redux-router, as I had many actions that relied upon componentWillMount and componentWillUpdate watching the url for changes.
Fastflux looks like a step in the right direction towards the promised land of of a functional-oriented UI written with javascript.
As someone with FRP experience, what do you think is the minumum viable set of functional transformers (like map, filter etc.) that should be implemented for a library like this?
6 comments
[ 3.3 ms ] story [ 12.8 ms ] threadFor instance: "Do we need yet another flux library?"
Well, why not? The ecosystem is still evolving. By bringing in more ideas and refined approaches, we may well reach equilibrium sooner.
But seriously, Fastflux just continues further in the logical direction established by Redux (and arguably React itself) -- a more reactive approach to software development.
Fastflux does this by using an implementation of the Observable FRP primitive as a superclass for stores and actions.
Also reduction of boilerplate.
Fastflux looks like a step in the right direction towards the promised land of of a functional-oriented UI written with javascript.
1: https://github.com/acdlite/redux-rx
As someone with FRP experience, what do you think is the minumum viable set of functional transformers (like map, filter etc.) that should be implemented for a library like this?