Show HN: Fastflux – Functional reactive state management for React
1–7 of 7 posts
Re: Show HN: Fastflux – Functional reactive state management for React
#2For 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.
Re: Show HN: Fastflux – Functional reactive state management for React
#3Re: Show HN: Fastflux – Functional reactive state management for React
#4Hey guys, feedback welcome. And I'll try to anwser any questions you may have. For 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.
Re: Show HN: Fastflux – Functional reactive state management for React
#5Fastflux looks like a step in the right direction towards the promised land of of a functional-oriented UI written with javascript.
Re: Show HN: Fastflux – Functional reactive state management for React
#6Hey guys, feedback welcome. And I'll try to anwser any questions you may have. For 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.
I'm going to ask the obvious one: What's your "sales pitch" compared to Redux?
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.
Re: Show HN: Fastflux – Functional reactive state management for React
#7As 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 fo…
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?