Open aweary opened 7 years ago
HI @aweary , you can use recompose / recompact lifecycle()
to do that.
Is exactly as @tlvenn mentioned, I just wanted to add that you are able to use this, as effects are received on props, and you can use props there in the fns you provide to lifecycle
, so this way you can trigger any effect you want on any lifecycle method (fn).
I understand that it's possible, this issue is about clarifying that in the documentation.
Also lifecycle()
or other composition utilities are just wrappers around class components. Their abstractions may be more consistent with freactal, but we should still demonstrate usage with lifecycle methods without requiring another level of abstraction
But from the point of view of the state, that is what freactal solves, it's OK to say that you could always use SFCs, what you are saying is more about the fact that you can't when you have lifecycle methods unless you use recompose/recompact
, or as you are saying use a class component, what I mean with this, that it's not something related to freactal but more with react itself.
but as far as I can tell, users will still need to use class components if they want to trigger effects in lifecycle methods
The wording your choose kinda led us to believe otherwise ;) But yes I agree, this should be documented and people shouldnt shy away from recompose/recompact with freactal.
In that regard, I dont think the doc should hint that freactal can potentially replace recompose. Imho, they complement each other. The only thing it will replace is the need to use the withState
that recompose is offering.
But from the point of view of the state, that is what freactal solves, it's OK to say that you could always use SFCs, what you are saying is more about the fact that you can't when you have lifecycle methods unless you use recompose/recompact
What I'm saying is that freactal provides no way to orchestrate effects based on React lifecycle methods. It stresses the point that you can use just SFCs, which you can in contexts where state updates are triggered from subscribers registered in render
like event listeners.
But real world applications will often trigger state updates in lifecycle methods, and it's worth documenting how this works because the current emphasis on SFCs and the lack of class lifecycle method examples leaves it ambiguous.
Agreed, @aweary. Let's get a solid example in there. Somewhere in the guide, maybe?
Was looking for a how-to guide to do exactly this and found this thread
edit: nvm, wrapped a class component and it works just fine
@cheapsteak did you mean composed instead of wrapped, for example
class Root extends React.Component {
render() {
return <h1>Root</h1>
}
}
const Parent = wrapComponentWithState(injectState(({ state }) => (
<Root state={ state }/>
)));
export default Parent
Something like that?
Yup! Exactly what I was wondering about, I should have just tried it out
The idea of deferring state management to
freactal
is solid but as far as I can tell, users will still need to use class components if they want to trigger effects in lifecycle methods, and the README seems to imply that you can always use SFCs becausefreactal
is orchestrating state, but that feels slightly misleading since React provides more than just state management APIsMaybe add an example uses a stateless class component triggering effects in lifecycle methods to make it clear that stateless doesn't always mean functional components?