Render Props and PureComponent docs question/improvement opportunity
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 11.8k
- Forks
- 7.9k
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 11
Description
In the above link, the last section ("Caveats") talks about how one can avoid killing PureComponents benefits by pulling the render prop function out into an instance method. I understand why this is the case; the 'anonymous' function 'pointer' would change every render, so it isn't seen as something that didn't change, and the PureComponent would re-render all the time.
However, it says you can't do that with a PureComponent if the instance method / render prop needs to reference the component's state/props:
In cases where you cannot define the prop statically (e.g. because you need to close over the component's props and/or state)
<Mouse>should extendReact.Componentinstead.
I don't really understand why that is a limitation, so I'm proposing this as both a question and a suggestion for an update to the docs. I've never used or really looked into PureComponent, but from a look at the docs for them it seems like they re-render if a shallow comparison of it's props/state shows a difference. If that's the case, why wouldn't an instance function on Mouse that used it's own props/state work with PureComponent? The Mouse would re-render if one changed.
(Is it because the Cat - the child component of the render prop Mouse - wouldn't re-render, even though it's parent would?)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read content/docs/render-props.md, especially the final “Caveats” section and its guidance about PureComponent. Clarify why an instance render-prop method that uses props or state is described as incompatible with PureComponent, including whether the child’s rendering behavior matters. Done means the documentation directly answers this question and explains the relevant limitation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, react
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100