编辑:在我看来,我认为React和高阶FRP概念的一个重大挑战就是处理React组件内部状态的问题,这暴露了用户不同于HO FRP的语言概念,在我看来,我觉得这也是一个更广泛的ES6 JS问题。我不是这方面的专家,但我分享我的想法和经验与我的玻璃钢之旅。
很多React的组件功能和组合依赖于JS class
语法。对我而言,这是一个挑战,因为你在混用术语和概念。对于很多前端开发人员(包括我自己)来说,React是他们第一次接触到FRP范例。当你一直用classes
和constructors
查看OOP继承术语时,很难理解功能组合的重要性。我认为这解释了为什么我们看到了与React库的这次爆炸,而不是那么多的基本范例 - 因为这里有一个完全混合的对比术语。与FRP Read this tidy little post相比,它更多地关注组件和DOM中心视图。
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,但我认为我们也不要把婴儿扔出洗澡水也很重要。
在丹·阿布拉莫夫的实用主义post about Redux他提醒我们,我们并不总是要坚持一种工具,并挂上一个范例,这并不是说我是反OOP我经常使用工厂和面向对象的概念在制作过程中,我认为使用面向对象的术语会让人有点困惑,然后开始谈论FRP。
东西看
正如评论所说,cycle.js是绝对值得一看。 React的声明式和可重用的组件结构与RxJS中的数据流和可观察性等概念的好处混合在一起。
这些是我的两分钱,我很想听听其他人是否有其他输入?
即使ELM(一阶FRP)停止beiig FRP:http://elm-lang.org/博客/告别frp,因为它太难学。那会是原因吗?人们不喜欢玻璃钢,因为它不熟悉? – jhegedus
它似乎正在发生,但没有与周期反应。 – jhegedus
可能只是人们害怕玻璃钢?我发现玻璃钢非常直观,但是对于一些人来说,FRP通常基于信号的配方似乎很难找到。反应实际上有一定长度,以隐藏它是基于玻璃钢内部。 –