具有React的高阶FRP - 为什么不发生?

jhe*_*dus 14 frp reactjs redux

Redux是一种一阶玻璃钢,就像以前的Elm一样.

然而,似乎更高阶的FRP并未真正与反应一起使用.

为什么第一阶FRP对React有用,而更高阶不太有用?

React可能不需要更高阶的主义?那么作为回报,可以保留时间旅行调试器吗?

换一种说法:

React是一个接受状态并返回视图的函数.

FRP是一种声明和执行状态机的方法.

这些是正交问题,为什么不将它们结合起来呢?

编辑:

如果我比较这个https://github.com/ochrons/diode/tree/master/examples/todomvc/src/main/scala/example

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

然后似乎使用scala.rx的相同应用程序是代码行的一半...而不是使用Diode(Redux像单向数据流库).

编辑2:

我的猜测 - 为什么它没有发生 - 是大多数高阶frp人(他们想在web开发中使用更高阶的FRP)使用reflex-frp,他们使用reflex-dom而不是反应.可能反射使得反应变得不必要了.

Mat*_*ent 1

编辑:在我看来,我认为 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)
Run Code Online (Sandbox Code Playgroud)

在我们的演示组件中

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

通过使用 Redux 的 HO 函数connect()mapStateToProps()mapDispatchToProps()允许使用仅接受状态和方法作为参数的纯函数组件。这些方法基本上可以返回任何内容。这无疑传达了更纯粹的高阶/一阶和 FRP 概念。

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

在 Dan Abramov关于 Redux的务实文章中,他提醒我们,我们不必总是只坚持一种工具并沉迷于一种范式,这并不是说我反对 OOP,我在生产中经常使用工厂和面向对象的概念,我只是认为使用 OOP 中的术语会有点令人困惑,然后开始同时谈论 FRP。

值得一看的东西

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

这是我的两分钱,我很想听听其他人是否有任何其他意见?