In React, there is a notion of "functional components" (which is to say, components defined as a single function). In essence, this is just the render function, with props as the argument:
var MyElement = ({ x, y, z }) =>
<div id={x}>
<a href={y}>{z}</a>
</div>These are both easier to read and promise future optimisations, so it would be good to get them involved. As I see it, there are two main cases where one can't use these:
- Anything involving component lifecycle (
shouldComponentUpdate, componentDidMount)
- Anything involving state (
getInitialState, setState, etc)
In these cases, we would need to fall back to class-declared components. There's a pretty trivial way to "lift" a stateless component into a class, should that need arise, which is why I'm here.
Could this library benefit from favouring the "functional" presentation of components where possible? My initial-thoughts-over-lunch involved a typeclass-based approach:
class WithState a b | a -> b
instance classWithState :: WithState ClassBased ClassBased
instance functionalWithState :: WithState FunctionalBased ClassBased
We can use functional dependencies to express how modifications will affect the given inputs. It could also be approached similarly to lens composition: certain operations "weaken" a FunctionalElement to a ClassDeclaration, for example.
I must admit that I haven't thought about this to a level that I'm satisfied with yet, but Phil suggested posting an issue so we could talk about it. What do people think?
In React, there is a notion of "functional components" (which is to say, components defined as a single function). In essence, this is just the
renderfunction, withpropsas the argument:These are both easier to read and promise future optimisations, so it would be good to get them involved. As I see it, there are two main cases where one can't use these:
shouldComponentUpdate,componentDidMount)getInitialState,setState, etc)In these cases, we would need to fall back to class-declared components. There's a pretty trivial way to "lift" a stateless component into a class, should that need arise, which is why I'm here.
Could this library benefit from favouring the "functional" presentation of components where possible? My initial-thoughts-over-lunch involved a typeclass-based approach:
We can use functional dependencies to express how modifications will affect the given inputs. It could also be approached similarly to lens composition: certain operations "weaken" a
FunctionalElementto aClassDeclaration, for example.I must admit that I haven't thought about this to a level that I'm satisfied with yet, but Phil suggested posting an issue so we could talk about it. What do people think?