编辑：在我看来，我认为 React 和高阶 FRP 概念的一个巨大挑战是，处理 React 组件内部的状态会让用户接触到与 HO FRP 无关的语言概念，在我看来，我觉得这是还有一个更广泛的 ES6 JS 问题。我不是这方面的专家，但我在 FRP 之旅中分享了我的想法和经验。

React 的很多组件功能和组合都依赖于 JSclass语法。对我来说，这是一个挑战，因为你混淆了术语和概念。对于很多前端开发人员（包括我自己）来说，React 是他们第一次接触 FRP 范式。当您一直在使用classes和查看 OOP 继承术语时，很难理解函数组合的重要性constructors。我认为这解释了为什么我们看到了 React 库的爆炸式增长，而不是底层范式 - 因为有完全不同的术语的混合。它更多地是关于组件和以 DOM 为中心的视图，而不是 FRP阅读这篇整洁的小帖子。

React 隐藏了很多底层概念，对于很多使用 FRP 范式的程序员来说，他们不喜欢这种神奇的感觉，这意味着新手很容易只使用class界面来制作他们的组件而不会暴露许多底层的 FRP 范式。

在我看来，在处理状态时，React 本质上应该是只读的。这样对待，React 和 Redux 就变得正交了。Redux 更倾向于 FRP 概念，实际上当以这种方式使用时，它变得更具声明性。

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)

在我们的展示组件中

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

通过使用终极版的HO功能connect()，mapStateToProps()并且mapDispatchToProps()它允许使用简单地采取国家和方法作为参数纯粹的功能组件。这些方法本质上可以返回任何东西。这当然传达了更高/一阶和 FRP 的更纯粹的概念。

虽然我相信我们会在应用程序和库开发中看到越来越多的 FRP 向前迈进，但我认为不要把婴儿和洗澡水一起倒掉也很重要。

在 Dan Abramov关于 Redux的实用帖子中，他提醒我们，我们不必总是只使用一种工具并沉迷于一种范式，这并不是说我反对 OOP 我在生产中经常使用工厂和面向对象的概念，我只是觉得使用 OOP 中的术语会有点混乱，然后开始同时谈论 FRP。

有什么要看的

正如评论中提到的，cycle.js绝对值得一看。在 React 的声明式和可重用组件结构与 RxJS 中数据流和可观察对象等概念的好处之间取得了很好的平衡。

这是我的两分钱，我很想听听其他人是否有其他意见？

它正在发生，它就在这里。我写了一个超级简单的、实验性的“网络框架”，它结合了钠 FRP、React 和 Scala.js。

我喜欢。我编写代码，我编译它，它可以工作。非常实验性的技术，尖端的 FP 东西。这是真正的交易。不妥协 FRP。