feat(reactivity): add pause/resume methods to ReactiveEffect
#9651
Conversation
Size ReportBundles
Usages
|
|
Not strictly related to the pr, but why are some private members starting with an |
Alfred-Skyblue
changed the title
pause/resume methods to effectpause/resume methods to ReactiveEffect
pikax
added
✨ feature request
Alfred-Skyblue
force-pushed
the
feat/effect/pause-resume
branch
from
7f7107a
to
406268d
Compare
|
@Alfred-Skyblue (Follow-up of this discussion) If there's not a better way to pass the "paused" state down (with inject/provide for example) and must be done with recursivity, instead of doing it from the top to the bottom as you suggested, what if it's done from the bottom to the top? I think it might be more efficient, since if I understood everything correctly, your proposal is O(n^d) and mine might be O(n) (in the best case). Imagine a frozen component (I think it's a good naming! More at the bottom...) that has 3 children and each children has another 10 components. With your suggestion, from the parent to the bottom, you'd need to first tell the 3 children that they're frozen, and these 3 need to do the same for their 10 children. That is 33 ops. However, what if the component that detects an update ask the parent chain if it's frozen before executing? You're assuming all children will need to trigger effects at some point, but they might not. In our previous example, only one of the inner childs might have an effect triggered: that child just needs to "ask" it's parent, which will "ask" the frozen component and freeze itself (so further requests from inner children will stop there). This should be more efficient (and we're not even taking into account the performance improvements of not altering the DOM while transitions are taking place!). I'm not so into the low-level details of how Vue works (I'm trying to!) so please bear with me if I'm saying stupid things, but I think this might not be as difficult, since you're already applying this PR to KeepAlive. Or this just "freezes" the first child of KeepAlive and not it's inner children in its current state? If we used a mechanism like provide/inject for this, I think it might be doable and efficient. As for the naming thing I said above: I think a good naming would be This API might also make it possible to create a |
|
@ferferga My expression may have been unclear. What I meant is to pause only the components that affect the Transition animation, without recursively pausing all child components. In other words, I will only invoke |
|
@Alfred-Skyblue Great then! That's exactly what I had in mind for my RFC and I think it should be enough to solve all the quirks demoed in the different playgrounds. I thought you meant that only pausing the first child node of Transition would not be enough and it had to be done recursively. |
yyx990803
force-pushed
the
feat/effect/pause-resume
branch
from
226dc48
to
272fb51
Compare
RFC: vuejs/rfcs#599
In this PR, a
pause/resumemethod has been added to theeffectto control whether theeffectcan be executed. When the effect is in a paused state and therunmethod is called, it will save the call once, and it can be immediately executed after calling theresumemethod. This is used in certain situations to improve performance by reducing unnecessary execution of effects, such as pausing in thedeactivatedstate of the keep-alive component, or implementing lazy updates in conjunction with IntersectionObserver.In #9206, derived classes were added for extension, aimed at controlling the
pause/resumeof therenderfunction. Following @antfu's suggestion, thepauseandresumemethods were added to theReactiveEffectclass. As theReactiveEffectclass has a widespread impact, a new PR has been opened.