1 Commits (eager-effect-rework)

Author	SHA1	Message	Date
Rich Harris	5bd4699539	chore: more efficient effect scheduling (#17808) ... This extracts part of #17805 into its own PR that can be merged independently. Today, if a (non-render) effect is created during traversal (e.g. an `{#if condition}` block becomes true, and an `$effect` is created somewhere inside it) then it goes through `schedule_effect`, ultimately causing the loop in `flush_effects` to run again. This is wasteful. We can instead push to an array — `collected_effects` — which is flushed following the first traversal. By using `collected_effects !== null` as a proxy for 'is traversing', we can also simplify the bail-out logic inside `schedule_effect` and make it work in more cases. Bailing out means that in the case that a signal is written to during traversal (which is the case for `each` blocks, for example), we can avoid triggering another turn of the loop because we know that the affected effects are about to be discovered as a result of the ongoing traversal. All this brings us slightly closer to the intermediate goal in #17805 of ensuring that scheduled effects always belong to a specific batch. No test for this because it shouldn't have any user-observable impact, though I've added a changeset out of an abundance of caution.	6 months ago