-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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: add $effect.active rune #14757
base: main
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: 0767c32 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 |
|
So, basically
Very nice! Arguably, this seems more useful than |
Essentially, yes. There's also some edge cases it handles. Like used in the teardown of an effect, or inside a derived that is "unowned", i.e. created outside of an effect. |
Hello. Will this cover #14329 ? |
cool, in those cases: teardowns and unowned deriveds, both would be false. updated use cases: bunch of use cases |
yeah, it covers anything within a component instance or outside of it if called from the instance. I created a playground with with console.log to compare |
Shouldn't
since there are no active effects |
sorry, this is just a typo in the comment, copy and paste. yes, both are always false in modules. updated |
We used to have this rune a while ago, back when it worked like
$effect.tracking
, this time it's back but operates differently. Now it will let you know if you're inside an active effect context. This is super useful for validation patterns where you want to warn people that some utility or API requires usage in specific parts of the codebase – such as a component or another effect.