-
-
Notifications
You must be signed in to change notification settings - Fork 243
feat(eslint-plugin): new rule prefer-signals #1872
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(eslint-plugin): new rule prefer-signals #1872
Conversation
☁️ Nx Cloud ReportCI is running/has finished running commands for commit 566c278. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 7 targetsSent with 💌 from NxCloud. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## next-major-release/v19 #1872 +/- ##
==========================================================
+ Coverage 90.99% 91.05% +0.06%
==========================================================
Files 181 183 +2
Lines 3475 3533 +58
Branches 580 595 +15
==========================================================
+ Hits 3162 3217 +55
- Misses 165 167 +2
- Partials 148 149 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
|
fc07c06
to
7103aeb
Compare
Edit: Done! ✔️ |
I'm strongly thinking we will want to have a It feels like I do agree with @MillerSvt that we need to at least have the option to use type information for enforcing signals usage. @reduckted would you like to collaborate on the |
Makes sense to just have a single I'd be happy to help out with that rule. Is #1824 the existing issue about it? In the meantime, I'll switch this PR to draft and update it to include type checking just so we have the implementation available somewhere. |
I've added two options:
|
… prefer-signal Added option to specify the types that should be replaced with a Signal.
…er query decorators
I've changed this rule to Feel free to critique anything that doesn't seem right, or isn't implemented in the preferred style. 😁 |
Would love to use it, when it merged. |
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.
Looking great!
Exactly what I am looking for. Looking forward to try it out when merged. |
any news on this? |
@JamesHenry is this something on your radar to review and complete soon? I think @reduckted addressed your concerns at this point |
I'm going to merge this into #2109 and apply some tweaks, many thanks again! |
db6e02b
into
angular-eslint:next-major-release/v19
Co-authored-by: Dave <reduckted@outlook.com>
@reduckted I wasn't fully happy with the scope of the arbitrary typesToReplace and the implementation only considered things being instantiated with |
We can revisit preferring signals over arbitrary things in a dedicated follow up |
Co-authored-by: Dave <reduckted@outlook.com>
Co-authored-by: Dave <reduckted@outlook.com>
Co-authored-by: Dave <reduckted@outlook.com>
Great addition, but the rule cannot be used, see #2149 |
Fixes #1719 and #1824.
This rule checks a few things.
Prefer Signals
This rule will report a problem when a
BehaviorSubject
is created. This type name can be overridden in the options. That allows this part of the rule to be skipped (by specifying an empty array), or to include additional types that should be replaced with signals.There is no suggestion for this part of the rule.
Prefer Readonly
This rule will report a problem for any class property that does not have the
readonly
modifier and either:Signal
InputSignal
ModelSignal
WritableSignal
computed()
contentChild()
contentChild.required()
contentChildren()
input()
input.required()
model()
signal()
viewChild()
viewChild.requried()
viewChildren()
This part of the rule can be disabled.
Prefer Input Signals
This rule will report a problem when
@Input
is used. This part of the rule can be disabled.Prefer Query Signals
This rule will report a problem when
@ContentChild
,@ContentChildren
,@ViewChild
or@ViewChildren
is used. This part of the rule can be disabled.