[no-misused-signals] restrict incorrect usage of signals - proposal #2302
Replies: 5 comments 1 reply
-
|
This seems to be a duplicate of #1753 and should probably be merged into a single issue. |
Beta Was this translation helpful? Give feedback.
-
|
Since signals are functions, this is also valid typescript code, but will never run, as const mySignal = signal(['hello', 'world']);
if (mySignal.length > 0) {
...
}Just happened to me recently when converting a component to use signals, and I'm recently sure that is not that uncommon |
Beta Was this translation helpful? Give feedback.
-
|
Thanks folks, it makes sense to me and I'll happily accept a PR for this rule |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I’d like to ask whether the fix has been merged and in which version. I haven’t been able to find it anywhere. Thank you in advance. |
Beta Was this translation helpful? Give feedback.
-
|
I released my own set of rules today, and I believe they could be useful for this proposal. It already covers quite a few of the ideas mentioned here. I'd be very grateful if you could check it out! https://github.com/rdlabo-team/eslint-plugin-rules/releases/tag/v20.0.0 |
Beta Was this translation helpful? Give feedback.
-
|
I’ve implemented a custom ESLint rule to check for Signals usage in templates, but I have to admit the approach isn’t ideal. When using templateUrl, the only way I found to validate the templates was to resolve and read the files manually using fs, since the template alone doesn’t provide enough context to determine whether something is a Signal. As a result, linting becomes quite heavy. Unless there’s a better way to handle this, I’m starting to think that supporting templates might be better suited for third-party tools. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Description of the proposal
This rule forbids providing Signals to logical locations such as if statements in places where the TypeScript compiler allows them but they are not handled properly. It could be about using signals in a nullish check or comparing them using operators like
===,==,>,<,>=, or<=. These situations can often arise due to a missing call or just a misunderstanding of the way signals are handled.In some rare cases
===or==operators can be valid. So need to add optionignoreNullishCheckto disable higlighting them.Reference: https://typescript-eslint.io/rules/no-misused-promises/
Incorrect code
@if (signal) { something } @if (signal === otherSignal) { something } @if (signal > otherSignal) { something } @if (signal < otherSignal) { something } @switch (signal) { something } {{ signal }}Correct code
@if (signal()) { something } @if (signal() === otherSignal()) { something } @if (signal() > otherSignal()) { something } @if (signal() < otherSignal()) { something } @switch (signal()) { something } {{ signal() }}Beta Was this translation helpful? Give feedback.
All reactions