Open alex-haproff opened 7 years ago
Hope this is getting in there as well!
For reference: https://www.reddit.com/r/reactjs/comments/68uqvb/freactal_deadsimple_composable_state_management/dh3ao4v/?context=3
That should be totally doable, but it there's no built-in solution for that right now. Would you mind opening an issue? I should have some time later in the week to address this and provide a baked-in solution.
@drcmda, to clarify, does using shouldComponentUpdate
and returning this.props.item !=== nextProps.item
. This places the burden on React rather than freactal, but the performance characteristics should be the same (I think). No matter what, you're going to be doing a lot of checks to see if the thing that was updated is the thing that is depended upon.
@alex-haproff, your issue is slightly different, and I'd like to provide a friendly interface to do what you want. You can already do that somewhat by specifying state keys to injectState
. That will inject those state keys as props, without any implicit Angular-esque magic. effects
is not spread into props
, but that's less of an issue, I think?
Why not just use something like mapProps
from recompose
?
import React from 'react'
import {compose} from 'ramda'
import {injectState} from 'freactal'
import {mapProps} from 'recompose'
const enhance = compose(
injectState,
mapProps(props => ({
value: props.state.counter,
onClick: props.effects.addOne,
})),
)
const CounterDisplay = ({value, onClick}) => (
<div>
<h2>Current counter value is: {value}</h2>
<button onClick={onClick}>Add one</button>
</div>
)
export default enhance(CounterDisplay)
This approach is doable with vanilla components and pure view components. You can inject state into the component, and then selectively pass state and effects into properties of the pure view that you do NOT inject state into.
that pure component is then outside the Freactal awareness sphere and treats your subset of parameters like conventional redux values. You can even mix in state from the container for localized freactal-less tossaway values. You can even rename properties and effects if it benefits you at this level.
The question becomes then: for the view component do you wrap it in injectState or not?
if you do NOT, then any of ITS children are cut off from the Freactal access.
if you DO injectState, then it will have an event property, a state property, and other props that are filtered from those objects -- a gain in clarity and emphasis, but also, some redundancy.
If you are going to strive for this level of control consider using shouldComponentUpdate to limit the components' refresh. If you are so convinced that you know exactly what this component should be listening to that you are taking control of it, you might as well go to the next level of management.
Great library, looking forward to trying it out in real projects. Is there any reason why I have to work with
state
andeffects
props in my components? Any reason for not having some sort of mapping functionality like in Redux, i.e. mapStateToProps/mapEffectsToProps? At the moment API feels slightly angular-esque and if I was to use dependency injection analogy - currently I have to pass an entire container into my components rather than individual dependencies. Hope this makes sense.