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?
<ChildComponent prop1={val}/>. The old school MVC is better. And Redux guys made all that FP hype more complicated. We need architecture instead of frameworks. – Permanent