15

Redux is a kind of first order FRP, like Elm used to be.

It seems however that higher order FRP is not really being used together with react.

Why is first order FRP useful with React and higher order not so useful ?

Maybe higher-order-ism is not needed with React ? So in return one can keep the time travelling debugger ?

In other words:

React is a function that takes a state and gives back a view.

FRP is a way to declare and execute a state machine.

These are orthogonal concerns, so why not combine them ?

EDIT:

If i compare this https://github.com/ochrons/diode/tree/master/examples/todomvc/src/main/scala/example

with this https://github.com/lihaoyi/workbench-example-app/blob/todomvc/src/main/scala/example/ScalaJSExample.scala

Then it seems that the same application using scala.rx is half as many lines of code... than with Diode (Redux like uni-directional data-flow library).

EDIT 2:

My guess - why it is not happening - is that most of the higher order frp folks (who want to use higher order FRP in web development) use reflex-frp, and they use reflex-dom instead of react. Probably reflex-dom makes react unnecessary.

jhegedus
  • 18,516
  • 11
  • 84
  • 147
  • 1
    Even ELM (first order FRP) stops beiig FRP : http://elm-lang.org/blog/farewell-to-frp , because it is too difficult to learn. Would that be the reason? People just don't like FRP because it is unfamiliar ? – jhegedus Sep 25 '16 at 04:55
  • 1
    It seems to be happening but not with react but with cycle. – jhegedus Dec 07 '16 at 19:22
  • Might just be that people are scared of FRP? I find FRP very intuitive, but the usual Signal-based formulation of FRP seems hard to grok for some people. React actually goes to some length in order to hide that it's based on FRP deep down. – Pedro Castilho Apr 15 '17 at 03:29
  • 1
    Well, I think React is not really related to FRP. React is just a rendering library, FRP is a way to describe a state machine. Orthogonal concerns. – jhegedus Apr 15 '17 at 23:18
  • 2
    By the way, the style of rendering and initialization at the same place (in render() method) of the child components in React lead to the whole FP hype. I wrote simple wrapper making it possible to use references instead of ``. The old school MVC is better. And Redux guys made all that FP hype more complicated. We need architecture instead of frameworks. – Brian Cannard Jun 15 '17 at 08:31
  • **+1 to the cycle.js comment**. Whilst I agree that all of these frameworks rely on paradigms and architecture that have been around for some time, it takes time to integrate these into modern implementations. To me cycle.js is in a sweet spot between super-lightweight and approachable. Taking a lot of influence from the Haskell stream-based I/O https://cycle.js.org/dialogue.html – Matthew Brent Sep 01 '17 at 02:54
  • @jhegedus In Javascript even the distinction between behaviors and events isn't common. Why bothering about time-varying values and how to express them when one can just mutate everything everywhere every time. Right, people should use these high level abstractions, but they don't. I guess it is a "cultural issue" of the Javascript community. –  Dec 01 '17 at 14:14
  • Cycle js plays together with react these days. https://staltz.com/use-react-in-cyclejs-and-vice-versa.html – PEZO Feb 16 '20 at 01:28

2 Answers2

1

EDIT: In my opinion, I think a big challenge with React and Higher Order FRP concepts specifically is that dealing with state inside React components exposes users to language concepts that aren't what HO FRP is about, In my opinion, I feel this is also a wider ES6 JS issue. I'm no expert on this subject, but i'm sharing my thoughts and experiences with my FRP journey.

A lot of React's component functionality and composition relies on JS class syntax. For me, this is a challenge because you're mixing up terminology and concepts. For a lot of front end developers (including myself) React was their first exposure to the FRP paradigm. It's hard to understand the importance of functional composition when you're looking at OOP inheritance terminology all the time with classes and constructors. I think that explains why we've seen this explosion with the React library and not so much the underlying paradigms - because there's a whole mixture of contrasting terminology. It became more about components and a DOM-centric view as opposed to FRP Read this tidy little post.

React hides a lot of the underlying concepts and for a lot of programmers who prescribe to the FRP paradigm they don't like how magic this feels, and it means it's easy for newcomers to just use the class interface to make their components and not get exposure to a lot of the underlying FRP paradigms.

In my mind, when dealing with state, React should essentially be read-only. Treated as such, React and Redux become orthogonal. Redux is much more skewed towards FRP concepts and actually when used in this way, becomes much more declarative. 

const mapStateToProps = (state, ownProps) => {
  return {
    id: ownProps.id,
    someData: state.projects.someData,
  }
}

const mapDispatchToProps = (dispatch) => {
  return {
    onSubmitForm(data) { //our callback
      dispatch( //redux dispatch function
        someAction(data) //our Redux Action Creator
      )
    }
  }
}

export default connect(mapStateToProps,mapDispatchToProps)(PresentationComponent)

and in our presentational component

const PresentationComponent = ({onSubmitForm, id}) => {
    return <form id="someForm" onSubmit={(e) => {
        e.preventDefault()
        onSubmitForm(getFormData(id))
    }}>
}

With the use of Redux's HO function connect(), mapStateToProps() and mapDispatchToProps() it allows the use of purely functional components that simply take in state and methods as arguments. These methods can essentially return anything. This certainly communicates a much purer concept of Higher/First Order and FRP.

Moving forward though I believe we will see more and more FRP in app and library development, but I think it's also important that we don't throw the baby out with the bath water.

In Dan Abramov's pragmatic post about Redux he reminds us that we don't always have to just stick to one tool and get hung up on one paradigm, it's not that i'm anti-OOP I use factories and object oriented concepts regularly in production, I just think it gets a bit confusing using terminology from OOP then start talking about FRP in the same breath.

Something to look at

As mentioned in the comments, cycle.js is definitely worth a look. It's a good balance between React's declarative and reusable component structure mixed with the benefits of concepts such as data streams and observables in RxJS.

Those are my two cents, i'd love to hear if anyone else has any other input?

Matthew Brent
  • 1,206
  • 11
  • 20
0

It is happening now, it is here. I wrote a super simple, experimental, "web framework", which combines Sodium FRP, React and Scala.js.

I like it. I write code, I compile it, it works. Very experimental tech though, cutting edge FP stuff. It's the real deal. No compromises FRP.

jhegedus
  • 18,516
  • 11
  • 84
  • 147