-
Notifications
You must be signed in to change notification settings - Fork 37
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
Create eslint plugin #709
base: main
Are you sure you want to change the base?
Create eslint plugin #709
Conversation
🦋 Changeset detectedLatest commit: 566d0e2 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 |
Deploying with Cloudflare Pages
|
Estimated impact to a consuming app, depending on which bundle is imported
|
@NullVoxPopuli, wondering if we could land MVP version of this plugins and iterate on it. |
If I understand this correctly it is the same for getters and if so I disagree with this rule. I've thought about it a lot and the thing is the reactivity to bar is a no-op anyway if foo is falsey. Thus it doesn't make much difference. As foo would have to react first before bar even came into the concerns of being consumed. Basically, the notion that bar needs to be consumed (registered as reactive) only matters when foo becomes truthy. For example, foo = false, bar = we don't care, In this case we wait till foo = true causing the code to re-execute under another consumption context in which case the second round foo is truthy and bar becomes consumed then registering it as reactive. The logic works out and the worry that bar has any effect on the re-calculation of the resource when foo is falsey is a mental model mismatch. I don't see how an eslint rule prevents any foot guns in this case. |
Goal is to help folks out with issues like what is reported here: #707
Todo: Lints for
warn: short circuiting logic can prevent other data from ever being consumed
in this situation, if both foo and bar are tracked, and foo is always false, the resource will never add
bar
to it's list of reactive dependenciesagainst: setting variables on
this
within a resourcetrackedFunction
resource()
from
)against: setting tracked state after the state was created (unless inside an awaited IIFE)
autofix: if
this
is accessed after an await, suggested and fix with destroyable protection (if isDestroyed || isDestroying) -- see also: Propose new rule: no-unsafe-this-access ember-cli/eslint-plugin-ember#1421Stretch goal lints