带有 React 的高阶 FRP - 为什么没有发生? [英] Higher order FRP with React - why is it not happening?

问题描述

Redux 是一种一阶 FRP，就像以前的 Elm 一样.

然而，似乎更高阶的 FRP 并没有真正与 react 一起使用.>

为什么一阶 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 而不是 react.可能 reflex-dom 使反应变得不必要.

解决方案

在我看来，我认为 React 和高阶 FRP 概念的一大挑战是处理 React 组件内部的状态使用户暴露于与 HO FRP 无关的语言概念，在我看来，我觉得这也是一个更广泛的 ES6 JS 问题. 我不是这方面的专家，但我正在与以下人员分享我的想法和经验我的 FRP 之旅.

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

React 隐藏了很多底层概念，对于很多使用 FRP 范式的程序员来说，他们不喜欢这种感觉有多神奇，这意味着新手很容易只使用 类 接口来制作他们的组件，而不是接触很多底层的 FRP 范例.

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

const mapStateToProps = (state, ownProps) =>{返回 {id: ownProps.id,someData: state.projects.someData,}}const mapDispatchToProps = (调度) =>{返回 {onSubmitForm(data) {//我们的回调dispatch(//redux 调度函数someAction(data)//我们的 Redux Action Creator)}}}导出默认连接(mapStateToProps，mapDispatchToProps)(PresentationComponent)

在我们的展示组件中

const PresentationComponent = ({onSubmitForm, id}) =>{返回 
{e.preventDefault()onSubmitForm(getFormData(id))}}>}

通过使用 Redux 的 HO 函数 connect()、mapStateToProps() 和 mapDispatchToProps() 它允许使用纯函数组件简单地将状态和方法作为参数.这些方法本质上可以返回任何东西.这当然传达了更高/一阶和 FRP 的更纯粹的概念.

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

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

要看的东西

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

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

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?

这篇关于带有 React 的高阶 FRP - 为什么没有发生?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！