-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: detach inert effects #11955
feat: detach inert effects #11955
Conversation
🦋 Changeset detectedLatest commit: 02d2bda The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
||
try { | ||
set_is_flushing_effect(true); | ||
execute_effect(effect); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it safe to execute the effect before linking it to its parent? If we have error boundaries in the future, I imagine we have to walk up the effect tree, but it's not constructed yet then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's an interesting point actually. If we have error boundaries in the future then the link will need to be there so we can find the nearest error boundary effect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The parent doesn't need to know about the child as long as the child knows about the parent, surely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh right, the parent is set - yeah that is probably enough
We create a lot of effects in the course of rendering an application, but many of them don't do any work after the initial execution. In some cases, they shouldn't really be effects in the first place — we're just abusing effects to defer some work until the DOM has been updated, and the actual position in the tree doesn't matter:
svelte/packages/svelte/src/internal/client/dom/elements/misc.js
Lines 15 to 19 in ddb0bc3
In other cases, they do need to be effects because we don't know whether they'll contain anything dynamic (e.g. an expression like
<p>{location.href}</p>
, or because the position in the tree is important (e.g.onMount
). But there's no need to keep them around if they're never going to update.This PR does two things:
I imagined this would be a fairly modest gain, but it's actually quite substantial. For a simple test like this...
memory usage in Chrome in prod mode drops 11% from 10MB to 8.9MB.
Before submitting the PR, please make sure you do the following
feat:
,fix:
,chore:
, ordocs:
.Tests and linting
pnpm test
and lint the project withpnpm lint