-
Notifications
You must be signed in to change notification settings - Fork 21
[CL-875] ADR 0029 - Adopt Angular Signals for Component State #638
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
base: main
Are you sure you want to change the base?
Conversation
|
Great job! No new security vulnerabilities introduced in this pull request |
|
Claude finished @willmartian's task in 1m 55s —— View job Code Review Complete
Review agent has completed analysis and posted findings to the PR. |
| Services tightly coupled to Angular should use signals. Services with business logic should prefer | ||
| RxJS for portability. Use `toSignal()` and `toObservable()` to bridge between the two when needed. | ||
|
|
||
| Existing code will be migrated gradually. New code must use signal-based APIs. |
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.
💭 Consider adding guidance on the migration strategy. Should this happen incrementally per feature area? Are there any teams or components that should be prioritized? ADR 0027 had a detailed "Implementation Plan" section which was helpful.
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.
🎨 I agree that this ADR needs an Implementation Plan section. I do not think that it needs to be overwhelming and could even point to some of the specific sections in the Angular Migrations Wiki
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.
My suggested approach would be for all teams to run the signal related migrations for all code they own, ideally feature by feature. But if we define a plan we also need to put weight behind it, we have plenty of existing ADRs with implementation plans that are pending.
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.
IMO, yes, the primary intent of a plan in an ADR is the steps by which each team will go through to accomplish the goal. We cannot set the timing of when the plan is done, but it does help to influence the timing when we can approach stakeholders showing a prescriptive plan on how to do the work.
|
I like the Claude feedback as of this writing so let's continue improving that. There's also https://contributing.bitwarden.com/contributing/code-style/web/angular/#reactivity-adr-0003--adr-0028 which can get a formal link. |
|
|
||
| As such, Signals should be the default when operating _in the view layer_: components, directives, | ||
| pipes, and services that are tightly coupled to the UI/Angular. Services that primarily deal with | ||
| business logic should prefer RxJS to maximize portability (or, even better, be moved to the Rust |
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.
🎨 I am good with the comment that suggests the usage of the Rust SDK.
That being said, I think it is important that an ADR be written to clearly describe that process. I do not currently see one published to our ADR Wiki.
I think it important for a few reasons:
A.) The codifying of the decision and migration plan to the Rust SDK aligns perfectly with our ADR mission statement
B.) Crafting it leaves behind a clear trail for teammates new and old to follow; minimized tribal knowledge around the migration
C.) Claude Code (or other agents) will hopefully be able to leverage the ADR to make suggestions to teammates working in the clients repo to move said business logic to the Rust SDK.
| Services tightly coupled to Angular should use signals. Services with business logic should prefer | ||
| RxJS for portability. Use `toSignal()` and `toObservable()` to bridge between the two when needed. | ||
|
|
||
| Existing code will be migrated gradually. New code must use signal-based APIs. |
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.
My suggested approach would be for all teams to run the signal related migrations for all code they own, ideally feature by feature. But if we define a plan we also need to put weight behind it, we have plenty of existing ADRs with implementation plans that are pending.
|
Can we add a admonitions to https://contributing.bitwarden.com/architecture/adr/observable-data-services linking to this ADR? I think it slightly supersedes the existing one. |
|
ADR 28 has just been taken by the way: https://contributing.bitwarden.com/architecture/adr/adopt-fusion-cache |
withinfocus
left a comment
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.
Lint.
Hinton
left a comment
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.
nits
|
Broken links looks like though:
|

🎟️ Tracking
https://bitwarden.atlassian.net/browse/CL-875
📔 Objective
Adds an ADR that describes our preference for signals over RxJS in Angular components.
⏰ Reminders before review
team
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmedissue and could potentially benefit from discussion
:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes