@@ -2,13 +2,13 @@
|
||||
|
||||
## Purpose
|
||||
|
||||
This report describes the lifecycle problem in `effect-fc-next`, why abandoned React renders leak Effect scopes, what the experimental implementations attempted, why those implementations are not satisfactory, and how a robust system should be designed.
|
||||
This report describes the lifecycle problem in `effect-view`, why abandoned React renders leak Effect scopes, what the experimental implementations attempted, why those implementations are not satisfactory, and how a robust system should be designed.
|
||||
|
||||
The experimental implementation discussed here has been removed from the source tree. This document is intended as design material for a clean reimplementation.
|
||||
|
||||
## Executive summary
|
||||
|
||||
The fundamental problem is not scope disposal by itself. It is that `effect-fc-next` performs Effect work and creates resource scopes while React is rendering.
|
||||
The fundamental problem is not scope disposal by itself. It is that `effect-view` performs Effect work and creates resource scopes while React is rendering.
|
||||
|
||||
React distinguishes between two broad phases:
|
||||
|
||||
@@ -467,7 +467,7 @@ interface ComponentScope {
|
||||
|
||||
Create it at commit and close it at effect cleanup. No registry, snapshot, subscription, speculative timer, or abandonment recovery is necessary unless runtime-wide disposal must independently own it.
|
||||
|
||||
## Final recommendation for `effect-fc-next`
|
||||
## Final recommendation for `effect-view`
|
||||
|
||||
Do not attempt to hide both committed component lifecycles and render-time Suspense resources behind one implicit `Scope` mechanism.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user