Skip to content
This repository has been archived by the owner on Feb 19, 2022. It is now read-only.

Clarify integration with class components and lifecycle methods #32

Open
aweary opened this issue May 5, 2017 · 11 comments
Open

Clarify integration with class components and lifecycle methods #32

aweary opened this issue May 5, 2017 · 11 comments

Comments

@aweary
Copy link

aweary commented May 5, 2017

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 because freactal is orchestrating state, but that feels slightly misleading since React provides more than just state management APIs

Maybe 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?

@tlvenn
Copy link

tlvenn commented May 5, 2017

HI @aweary , you can use recompose / recompact lifecycle() to do that.

@mgtitimoli
Copy link

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).

@aweary
Copy link
Author

aweary commented May 5, 2017

I understand that it's possible, this issue is about clarifying that in the documentation.

@aweary aweary added the docs label May 5, 2017
@aweary
Copy link
Author

aweary commented May 5, 2017

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

@mgtitimoli
Copy link

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.

@tlvenn
Copy link

tlvenn commented May 5, 2017

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.

@aweary
Copy link
Author

aweary commented May 5, 2017

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.

@divmain
Copy link
Contributor

divmain commented May 8, 2017

Agreed, @aweary. Let's get a solid example in there. Somewhere in the guide, maybe?

@cheapsteak
Copy link

cheapsteak commented Oct 6, 2017

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

@AddictArts
Copy link

@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?

@cheapsteak
Copy link

Yup! Exactly what I was wondering about, I should have just tried it out

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants