-
Notifications
You must be signed in to change notification settings - Fork 49.2k
Closed
Description
I'll use this gather a few ideas of new life-cycle methods that help avoid existing problematic cases when using Fiber or other async rendering solutions.
componentDidServerRender
: Gets called after the entire tree has rendered on the server. Useful for aborting buffered renders, or logging. Got the idea from Deprecate componentWillMount Maybe? #7671. This could possibly replacecomponentWillMount
.componentWasMounted
andcomponentWasUpdated
: Similar tocomponentDidMount
andcomponentDidUpdate
but happens asynchronously in spare cycles after a component has already appeared on the screen. That way triggering things like I/O doesn't have to block the component from rendering on the screen and dropping frames sincecomponentDidMount
have to be synchronous. This is not appropriate to use for Flux store subscriptions since you may be missing events that way. However, we can use "lazy subscriptions" as an alternative solution. componentWasMounted/componentWasUpdated (formerly componentDidDisplay) #5053.componentWasUnmounted
: Similar to the above, this would happen in spare cycles for clean up purposes where clean up is not synchronously needed. This may not be needed as a separate life-cycles since we can possibly just makecomponentWillUnmount
async. Defer Execution of Unmount Life Cycle Hooks #6003.componentWillMountNow
andcomponentWillUpdateNow
: This would be a fiber specific thing. Unlike the currentcomponentWillMount
/componentWillUpdate
it actually happens afterrender
and after all the children'srender
have been called, but right before any side-effects are committed to the DOM. The use case of reading the current scroll position incomponentWillUpdate
only to reset it later doesn't work with async rendering because you can scroll betweencomponentWillUpdate
andcomponentDidUpdate
. This could possibly replacecomponentWillUpdate
.
bvaughn, dashed, dderevjanik, faalsh, riqswe and 13 more