Higher order FRP with React - why is it not happen

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.

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?