Simplify composite lifecycle state #1560
Conversation
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
There was a problem hiding this comment.
Then you can remove it from the diagram as well. (Also noticed there's a duplicate column in the diagram!)
Tangent: (Why doesn't github let me comment on the line by the diagram and I am forced to comment here?)
There was a problem hiding this comment.
Updated the diagram, though I'm not sure it's exactly what you wanted. To be honest, I am not sure exactly what the diagram is trying to demonstrate.
There was a problem hiding this comment.
It's just demonstrating that there are two lifecycles (Component and Composite) that are almost independent of each other - they overlap and but only certain combinations are even valid.
We now forbid calling setState or forceUpdate if any component's render function is higher in the stack, not just the component you're trying to update. (We do this already now for React.renderComponent and React.unmountComponentAtNode.) This also has the advantage that we can now remove CompositeLifeCycle.RECEIVING_STATE, making _compositeLifeCycleState easier to reason about (not to mention that RECEIVING_STATE was a confusing name) and making it possible to remove a try/finally from the render path which might help with perf.
Simplify composite lifecycle state
4 participants
We now forbid calling setState or forceUpdate if any component's render function is higher in the stack, not just the component you're trying to update. (We do this already now for React.renderComponent and React.unmountComponentAtNode.)
This also has the advantage that we can now remove CompositeLifeCycle.RECEIVING_STATE, making _compositeLifeCycleState easier to reason about (not to mention that RECEIVING_STATE was a confusing name) and making it possible to remove a try/finally from the render path which might help with perf.