-
Notifications
You must be signed in to change notification settings - Fork 1
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
refactor: use Signal::get_untracked() in non reactive contexts #800
Conversation
Reviewer's Guide by SourceryThis pull request replaces the usage of the reactive No diagrams generated as the changes look simple and do not need a visual representation. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
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.
Hey @hrzlgnm - I've reviewed your changes - here's some feedback:
Overall Comments:
- It looks like you're consistently using
get_untracked
in these contexts, which is good for performance. Consider adding a comment explaining whyget_untracked
is necessary in these specific cases to improve readability.
Here's what I looked at during the review
- 🟢 General issues: all looks good
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟢 Complexity: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Also deduplicate the service_type input empty condition while deriving the signal.
Summary by Sourcery
Use Signal::get_untracked() in non-reactive contexts to avoid unnecessary re-renders.