Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pass context to render in ReactCompositeComponent. Related to #1387 #3350

Closed
wants to merge 1 commit into from

Conversation

nhunzaker
Copy link
Contributor

Not a super big deal, but I wanted to put some legs behind #1387.

I'm not really sure this is all that is required, but this change should allow props and state to be passed to the render() method by passing in the component instance:

render({ props, state }) {
    return <p>{ props.thing }</p>
}

@akre54
Copy link
Contributor

akre54 commented Mar 10, 2015

You could do something similar with .call and a {props, state} object. Not especially clean, but syntactically similar and wouldn't require a signature change.

I personally would like to see render(props, state) added to encourage pure render functions, but I also realize it might break expectations if the rest of your component methods have to use this.props.foo and this.state.foo.

@nhunzaker
Copy link
Contributor Author

@akre54 Actually, on the related issue (#1387) there was discussion about render(props, state) being problematic with replaceState and replaceProps. Seeing as how they are now deprecated I wonder if that's a more realistic goal.

@zpao
Copy link
Member

zpao commented Apr 9, 2015

cc @sebmarkbage - anything you want to do about this in the short-term?

@sebmarkbage
Copy link
Collaborator

Basically, our thinking has been that this should be consistent with life cycle methods (which get nextProps, nextState, nextContext or previousProps, previousState, previousContext and also uses this) and how you do things in callbacks (which uses this).

We've been exploring ways of expressing callbacks in a way that they also receive props, state, context in the same way. We haven't landed on anything there yet though. Therefore the idea was to wait on something here until we know where we're heading with that API.

One design philosophy we have is that there generally shouldn't be two different ways to do the same thing in arbitrarily different ways. That creates bikeshedding and confusion.

I think the next thing we could do is allow constructors to return a ReactElement. This is the stateless function proposal in react-future. Perhaps this is a good start to encouraging pure functions.

@sophiebits
Copy link
Collaborator

Closing for now.

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

Successfully merging this pull request may close these issues.

6 participants