- Ben (React)
- Jim (React)
- Keyan (React, intern)
- Paul (React)
- Sebastian (React)
- Shayne (React Native)
- Tom (React)
Getting Rid of
- This is one of the most commonly used mixins.
- We need to have a good story around applying it to classes and SFCs (stateless functional components).
- Let’s consider a few alternatives.
PureComponent and heuristics for SFCs
React.PureComponentbase class (kinda like a class with
- Make SFCs “inherit” their purity from the closest class-based parent.
- This works because if the class above is pure, SFC wouldn’t re-render anyway.
- Implemented in #6914 with some additional explanation here.
- Any heuristics based model will probably not work in 100% of cases, and could cause confusion.
- If you pass children through, you don’t know anything about them, including whether they use mutation.
- Warn if a
PureComponenttakes in a child element (or child element which changes).
- In dev mode, do dry-run reconciliation past all
shouldComponentUpdates and warn if
shouldComponentUpdatelied to React.
Proposal 2: SFCs Always Shallowly Compare Props
- Effectively a
PureRenderMixinon every SFC.
- Means that component authors generally can’t / shouldn’t use SFCs because
PureRenderMixinshouldn’t be used with components that take children.
- Performance. It’s not clear that adding
PureRenderMixinto every SFC would actually improve overall performance (because it means extra reads/compares, retaining objects longer and into subsequent GC generations, etc).
- Provide some flag on components at the calling side to denote that they should be pure.
- This would tell React to effectively “use
PureRenderMixin” on that particular instance, not all instances.
- Many syntax possibilities:
ES Class Progress
- Ben is leading the effort to port Facebook codebase to ES classes.
- We plan to enable property initializer syntax internally, and codemod all methods except lifecycles to it.
Please feel free to discuss these notes in the corresponding pull request.